toolchain list omits targets this host can build for #504

mcpp toolchain list filters vocabulary rows through host_can_serve, which answers can this host serve the target from a payload. It then presents that answer as can this host build for the target. Those are different questions, and one row separates them today.

Measured

Host: Linux x86_64, 2026-08-25, mcpp 2026.8.25.1.

x86_64-windows-musl does not appear in mcpp toolchain list. The same host builds it:

$ mcpp build --target x86_64-windows-musl
         kernel-abi  openkal  (openkal-windows@0.1.5, graph)
         c-abi       musl     (openkal-musl@0.3.5, graph)
         c++-abi     libc++   (openkal-llvm-runtime@0.1.3, graph)
    Finished dev [unoptimized + debuginfo] in 2.95s

$ file target/.../winmusl.exe
PE32+ executable (console) x86-64, for MS Windows, 14 sections

A real PE, from a Linux host, for a target the tool's own answer to "what can I build for?" leaves out.

Why the filter is right and the use is wrong

host_can_serve returns false for this row on a non-Windows host, and correctly so — there is no prebuilt Windows/musl system to install. The target's own table row says what happens instead:

The C library still comes from the dependency graph. host_can_serve says no for this row on a non-Windows host — correctly, for the prebuilt system — and that refusal is diagnosed early and RELEASED once the graph is known.

prepare.cppm already implements that release (unservedTargetDiagnosis). lifecycle.cppm's listing loop has no equivalent, so a row that a build would accept is dropped from the list.

Not every absent row is this

x86_64-windows-msvc and aarch64-macos are also absent on a Linux host and are absent correctly: MSVC and the macOS SDK are host-only, and no dependency graph substitutes for them. A fix must keep those out.

What it needs

A predicate for "the graph can supply this target's system on this host", which does not exist yet — host_can_serve is about payloads and the table has no column for it. Listing a target that cannot in fact be built here would be worse than the present omission, so this wants a real predicate rather than a heuristic over pin or is_musl().

Found during the #503 review. Deliberately not fixed there: #503 fixes four defects that are all a predicate applied to a question narrower than itself, and adding a guessed predicate to that PR would be the same mistake.