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

…the lib-root decision finished

`cl.exe` consumption was already implemented; what was missing was verification
and a docs table that had not followed the prose. Both ends now: a portable unit
test over the renderer, and an e2e whose consumer pins `msvc@system`, because a
clang consumer passes whether or not the neutral form is used and therefore
proves nothing. The e2e also asserts the leg's `-L` is absent from the generated
graph — "it linked" could otherwise mean cl was merely tolerant.

⚠️ And a finding that runs against the previous round: `-L` vs `/LIBPATH:` is a
DIALECT question, not a target-ABI one, because those flags go to whatever mcpp
invokes rather than to the linker. Clang targeting the MSVC ABI separates all
three axes — GNU dialect, MSVC-ABI objects, PE image — and asking it the wrong
one fails differently each time. docs/08 §7.5 is that table, in both languages.

The lib-root decision was only half fixed last round. `validate.cppm` warned that
an `.ixx` project's lib root was missing when it was right there, and
`prepare.cppm` handed a host-module dependency a path to a file that does not
exist. Control-verified: the released 2026.8.18.2 binary emits
`warning: src/mathkit.cppm: lib target without conventional lib root` on a
project whose interface is `src/mathkit.ixx`. e2e 263 pins one assertion per CALL
SITE, with a negative control — without it the test would also pass against a
validator that simply stopped checking.

Two more things 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 with nothing to fix.
* the data-symbol `dllimport` limit is now reproducible rather than prose. 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/05 gains the rule the hard error follows from — every entry `sources`
matches must produce an object that gets linked — and the 简体中文 page, which
was missing even the `sources = []` note, gets both.

…om its suffix

macOS CI, on the test written two commits earlier:

    clang++: error: no such file or directory: …/.build-mcpp/rulepkg.pcm
    clang++: error: no input files

`clang++ --precompile rulepkg.ixx -o rulepkg.pcm` EXITED 0 AND WROTE NOTHING.
Clang's driver does not recognise `.ixx`, so it treated the interface as a linker
input, warned that it was unused, and succeeded — and the failure surfaced one
step later naming an OUTPUT rather than the input that was never read.

Every other module compile in mcpp already states the language explicitly
(`BmiTraits::moduleInterfaceLangFlag` — `/interface /TP`, `-x c++-module`,
`-x c++`). The host-module path was the one place still letting the driver guess,
and it is the fourth place this round where an extension had to stop being a
proxy for a decision.

Two changes, both small: the language flag goes in positionally before the input
for the clang and GCC branches (MSVC already passed `/interface` + `/TP`), and
the precompile now checks that a BMI actually appeared. A step that can succeed
without producing its output must say so where the input is still in scope,
otherwise the next step blames a missing file.

Reproduced locally under `MCPP_TOOLCHAIN=llvm@22.1.8` — which is what makes this
a fix rather than a guess at what macOS meant — and 189/193, the existing
host-module tests, still pass on both toolchains.