fix: cl.exe consumption verified, the flag-axis rule written down, and the lib-root decision finished

[Sunrisepeak]

Implements the plan in
.agents/docs/2026-08-18-open-items-analysis-and-axis-discipline.md. The four
items 2026.8.18.2 left open turned out to be three instances of one mistake and
one deliberate break.

cl.exe consumption: already implemented, never verified, and the docs said ❌

The dialect-neutral [target.<pred>.runtime] mechanism shipped last round. The
limits table in docs/12 still said ❌ see below while the prose beside it
described the solution — which is precisely what the project's own docs style
rule about matching claims to evidence exists to prevent.

Verified from both ends now:

• test_link_intent_spelling.cpp — portable, runs on all three platforms;
• e2e 262, whose consumer pins msvc@system. That is the criterion: if the
  neutral form were ignored and the ldflags applied, a clang consumer would still
  link, so only cl — which stops at the first -L — can prove anything. The
  test also asserts the leg's -L is absent from the generated graph, because
  "it linked" could otherwise mean cl was merely tolerant.

⚠️ A finding that runs against last round

Last round fixed three flags that were keyed on the dialect and belonged to the
target. It is tempting to call if (isMsvcDialect) return PeMsvc a fourth. It
is not, and the difference is now written down in docs/08 §7.5:

axis	the question	examples
target format	what image is produced	-fPIC
target ABI	which linker consumes this	--out-implib / /IMPLIB:, /DEF:
dialect	which program mcpp invokes	-L / /LIBPATH:

Clang targeting the MSVC ABI separates all three — GNU dialect, MSVC-ABI objects,
PE image — and asking the wrong one fails differently each time. The table exists
so the next person adding a flag does not rediscover this one platform at a time.

The lib-root decision was only half fixed

Last round fixed the resolver the packer uses and left two callers behind:

• validate.cppm warned that an .ixx project's lib root was missing when it
  was right there;
• prepare.cppm handed a host-module dependency a path to a file that does not
  exist.

Control-verified against the released 2026.8.18.2 binary on the same fixture:

warning: src/mathkit.cppm: lib target without conventional lib root
         'src/mathkit.cppm' (create the file or set [lib].path)

e2e 263 pins one assertion per CALL SITE, with a negative control — a project
with genuinely no lib root must still be warned about, or the test would pass
against a validator that simply stopped checking.

Two more the work turned up

• A host-module dependency was warned about a dead module_extensions entry.
  Its source globs are emptied on purpose — that is what keeps a build rule out
  of the consumer's binary — so every declared extension looks dead, and the
  rule's author sees a warning about their own correct manifest, in every
  consumer's build, with nothing to fix.
• The data-symbol dllimport limit is reproducible instead of prose (e2e
  258). The assertion is the DIFFERENCE between the two spellings, not an error
  text: which form the failure takes depends on the toolset, and pinning one
  would make the test a hostage to it. If reading exported data without
  dllimport ever starts working, the test says so and names the documentation
  as the thing to fix.

Docs

docs/05 gains the rule the previous round's hard error follows from — every
entry sources matches must produce an object that gets linked — so it reads as
a consequence rather than a new prohibition. The 简体中文 page was missing even
the sources = [] note; both are there now.

Notes for review

• Local: 239 passed, 1 failed, 15 skipped; the failure is
  22_doctor_cache_publish, which the previous RELEASE binary fails identically
  on this machine.
• Built with both gcc and clang (a name attached to two modules is a clang-only
  error).
• e2e 262 and the extended 258 are # requires: msvc — Windows CI is the only
  place they run, and the merge criterion is that they are seen to RUN there.