feat(windows): MSVC DLLs export, packages link with cl.exe, and module_extensions is followed everywhere

[Sunrisepeak]

Closes the three questions left open by 2026.8.18.1, from
.agents/docs/2026-08-18-windows-shared-library-and-module-extensions.md. They
shared a shape: mcpp treated "the toolchain does not do this for us" as "this
cannot be done", and each had an industry answer older than a decade.

kind = "shared" works on the MSVC ABI

MSVC exports nothing from a DLL without __declspec(dllexport) or a .def, so
the import library came out empty and consumers failed with unresolved externals
for symbols visibly in the objects. The reason was right; the conclusion
was not. CMake has shipped WINDOWS_EXPORT_ALL_SYMBOLS since 3.4, and its
bindexplib reads COFF directly — decisive here, because dumpbin lives in a
Visual Studio developer environment and mcpp's default Windows toolchain is
clang, so a plain mcpp build is not inside one.

mcpp.build.coff_exports is that reader, a pure function over bytes so it
can be tested on hosts that cannot produce COFF at all. 16 unit tests build
objects byte by byte — the only way to vary a storage class on demand — plus two
committed real mingw objects, because a reader fed only its own test's output
agrees with itself and nothing else. Past 65535 exports it refuses rather than
truncates: a truncated export table links cleanly and fails at whichever
consumer needed the symbol that fell off the end.

Annotation wins. An object already carrying /EXPORT: directives — what
__declspec(dllexport) emits — makes mcpp stand down. Adding a list on top would
export the same names twice (LNK4197) and export everything else besides,
replacing a chosen public surface with all of it. Detected, not configured: a key
for "I annotated my exports" is a second place to say what the objects say.

Two limits survive that no tool removes, and they are CMake's documented ones for
the same mechanism — exported data still needs dllimport on the consumer,
and a class whose vtable is referenced must be marked whole. Both are in
docs/12 rather than left to be discovered.

A package can be consumed by native cl.exe

The generated manifest now also carries the dialect-neutral
[target.<pred>.runtime] pair, which mcpp renders as /LIBPATH: + <n>.lib or
-L + -l<n>. Not new vocabulary — the same two keys [runtime] has had at top
level, made per-target. Both spellings ship: an older mcpp reads only the
ldflags and silently ignores the new block, so dropping them would leave every
older client with no link line.

⚠️ One leg is deliberately excluded, and e2e 257 is why. A PE/MinGW shared
leg links with -L… -Wl,-Bdynamic -lmathkit, and -Wl,-Bdynamic only works
immediately before the -l it enables. Two attempts to route it through the
neutral channel both failed with have you installed the static version of the mathkit library? — first by clearing the ldflags, then by rendering the library
reference into a different command-line slot. Both were the same mistake:
treating a hand-tuned link line as a two-field record.

module_extensions is the knob, and everything follows it

.ixx is not built in — the extension set is configuration, not a list mcpp
grows one entry at a time. What that owes in return is that one declaration is
enough, and three places were not holding up their end.

The scanner accepted what it could not classify. An undeclared .ixx
produced a compile edge whose object nothing links:

build obj/mathkit.ixx.o | gcm.cache/mathkit.gcm : cxx_object …
  bmi_out = gcm.cache/mathkit.gcm      ← the BMI was produced
build bin/app : cxx_link obj/main.o    ← the object is not here
ld: undefined reference to `mk::answer@mathkit()'

Two answers to "is this a module interface" and only one of them read.

The lib-root convention hard-coded .cppm, so packing an .ixx library
started its closure at a file that does not exist — and the result was silently
wrong twice over:

$ mcpp pack mathkit
     Interface (headers only)      ← the module interface, gone
      Withheld (nothing)
  Packed …-x86_64-linux-gnu        ← the C-SURFACE tag

An empty published set is precisely how the packer recognises a C surface, so
losing the interface also stopped the package constraining the C++ ABI, and
the compatibility gate stopped checking compiler and stdlib.

The generated manifest listed .ixx sources without saying what an .ixx is.
It now declares the extension — computed from the published files, so it cannot
disagree with sources, and absent for a .cppm package whose manifest is
unchanged.

Notes for review

• ⚠️ Behaviour change: a sources entry mcpp cannot classify is now a hard
  error. A project with a .md in sources starts failing.
• ⚠️ The probing lib-root resolver lives in mcpp.manifest.toml, not beside its
  sibling in types — measured: adding the extension-table import to types,
  which nearly everything depends on, made GCC 16.1 ICE while compiling an
  unrelated src/main.cpp, with a cleared gcm.cache. The edge is not added;
  the function moved to where the edge already is.
• Local: 239 passed, 1 failed, 14 skipped. The failure is
  22_doctor_cache_publish, which the previous RELEASE binary fails identically
  on this machine.
• Still unverified: the cl.exe consumption path end to end (needs a consuming
  case in the msvc job), and the data-symbol dllimport limit is documented but
  has no reproducing test.