docs(record): the wasm row's numbers were two releases stale, and the upgrade path is measured across two binaries

THE CORRECTION LANDED IN THE RECORD AND NOT IN THE CODE. The design document
carries the re-taken 2026-09-11 measurement -- Emscripten 6.0.9 reports
`_LIBCPP_VERSION 220108` (llvm 22.1.8) and clang 24.0.0git -- while the
`wasm32-emscripten` row's own comment still said llvm 20.1.7, `200100` and
clang 22.0.0git. Two copies of one decision, and the second written without
reading the first.

The rule those numbers support is unaffected and is exactly why they have to
be right: the module surface must match the LIBRARY, never the compiler. A
stale number in a comment becomes a stale number in a diagnostic, and then in
somebody's install command.

Also simpler than the comment first said: 6.0.9 SHIPS the surface (134 files),
so `em++` links `import std` with no generated surface at all.

SECTION 11.8 GAINS A TWO-BINARY MEASUREMENT. An absent-tolerance claim is
about what a previous version wrote, so a unit test over a synthesised header
is not the whole criterion:

  1. released 2026.9.10.2 writes `graph=normal;schedule=none;accel=default`
  2. 2026.9.11.2 appends `;dist=none` -- fingerprint change, full rebuild, no error
  3. 2026.9.11.2 again -- `Finished dev in 0.00s`, the fast path replays
  4. 2026.9.10.2 again -- `0.00s`, the downgrade does not choke

Step 4 says what the tolerance is worth: the version is in the fingerprint, so
two binaries never share a graph directory and an older mcpp never reads a
`dist=` field at all. The read side is defence in depth rather than a live
path -- the same conclusion 11.2 reaches from the other direction.

Author: speak-agent

.agents/docs/2026-09-11-distribution-plugins-and-platform-decomposition.md

@@ -1116,6 +1116,22 @@ unpersisted declaration would be absent exactly when a user names a format.
 carries no such line and the program that wrote it could not emit one, so
 replaying it yields what that program said.
 
+Measured across two real binaries rather than only in a unit test, because an
+absent-tolerance claim is about what a *previous version* wrote:
+
+| step | binary | the graph's header line | result |
+|---|---|---|---|
+| 1 | released 2026.9.10.2 | `graph=normal;schedule=none;accel=default` | builds |
+| 2 | 2026.9.11.2 | `;dist=none` appended | fingerprint change, full rebuild, no error |
+| 3 | 2026.9.11.2 | unchanged | `Finished dev in 0.00s` -- the fast path replays |
+| 4 | 2026.9.10.2 again | its own older directory | `0.00s` -- the downgrade does not choke |
+
+Step 4 also says what the absent-tolerance is worth. The version is part of the
+fingerprint, so two binaries never share a graph directory and an older mcpp
+never actually reads a `dist=` field. That makes the field's read side defence
+in depth rather than a live path -- which is the same conclusion §11.2 reaches
+from the other direction, and is why the invariant is held in a unit test.
+
 ### 11.9 Test coverage
 
 The count is not the measure; what each test excludes is. Two are worth naming.

modules/toolchain-model/src/triple.cppm

@@ -576,12 +576,21 @@ inline constexpr TargetInfo kKnownTargets[] = {
     // repeated at every site that needed it. That is why this is
     // https://github.com/mcpp-community/mcpp/issues/597 and not a table row.
     //
-    // IT IS NOW ONLY THAT. The standard-library half is answered: measured
-    // 2026-09-11, `em++` compiles and links `import std` with NO additional
-    // flags once the module surface from llvm 20.1.7 is present -- the release
-    // matching Emscripten's `_LIBCPP_VERSION` of 200100, not the 22.0.0git its
-    // clang reports -- and `node app.js` printed the expected output. So #597
-    // is one problem rather than two.
+    // IT IS NOW ONLY THAT, AND THE STANDARD-LIBRARY HALF IS SIMPLER THAN THIS
+    // COMMENT FIRST SAID. Measured 2026-09-11 against Emscripten 6.0.9:
+    // `em++` compiles and links `import std` with NO additional flags and no
+    // generated surface at all, because the toolchain SHIPS one -- 134 files
+    // -- and `node app.js` printed the expected output.
+    //
+    // The version numbers here were two releases stale, in exactly the
+    // direction the design record warns about: they said llvm 20.1.7 and
+    // `_LIBCPP_VERSION 200100` against clang 22.0.0git. Emscripten 6.0.9
+    // reports `220108` (llvm 22.1.8) and clang 24.0.0git. The rule those
+    // numbers were supporting is unaffected and is the reason to keep them
+    // accurate: the surface must match the LIBRARY, never the compiler, and a
+    // recipe's job is to pin the `_LIBCPP_VERSION` it measured and refuse a
+    // change. A stale number in a comment becomes a stale number in a
+    // diagnostic, and then in somebody's install command.
     //
     // `defaultStatic` is true because wasm has no dynamic loader in the sense
     // the other rows mean: an Emscripten link produces one module plus its