test: C9 is only half fixed — the libm half survives FPSemantics

All 9 tests green. LargeSeedSurvives proves C1 fixed by property rather than by
comparison: seed 2e9 (what FMath::Rand produces) now yields 400 distinct heights
over 400 samples where it previously gave a constant field. The three equivalence
tests stayed green through an 85-site rewrite.

The digest's NearIso warning fired at 2/115000 and its text blamed the /fp:fast vs
precise split, which is fixed. First instinct was "stale warning, soften it". Checked
instead, and the risk is real by a different mechanism:

sinf/cosf are not specified by IEEE-754. FPSemantics = Precise makes MSVC and Clang
agree on expression evaluation and says nothing about the math library; MSVC's CRT
and glibc's libm may differ by ~1 ULP. FMath::Sin/Cos are used throughout the density
path — layer lines, ribs, room placement, rotations. So C9's compiler half is closed
by construction and its library half is not, and no build flag can close it.

The measurement was also over-stating by ~100x: a single 1e-4 band is far too wide
for a libm-scale delta (~1e-6 absolute at densities of magnitude ~10). Replaced with
a three-band profile; only the tight band warns.

UNVERIFIED: the reworded test.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

AUDIT-2026-07.md

@@ -302,9 +302,29 @@ reachable only with a very large origin room *and* short tunnels. Flagging it be
 > (`ClangToolChain` → precise, `VCToolChain` → `/fp:fast`). That is not a theoretical divergence.
 > Same-platform peers on the same build are fine.
 >
-> **The fix is known and blocked:** `FPSemantics = Precise` on this module, which needs the IWYU debt
-> cleared first (seven headers compile only via the shared PCH). That debt is now worth clearing on
-> *this* justification rather than on tidiness.
+> ### ✅ HALF FIXED 2026-07-27 — and the other half is a different mechanism
+>
+> **`FPSemantics = Precise` is set** (IWYU debt cleared to allow it). MSVC now gets `/fp:precise`,
+> Clang gets `-ffp-contract=off`; both are IEEE-754 with no contraction, so **the compiler half is
+> closed by construction.** It also dissolved `§C10` entirely.
+>
+> **⚠️ THE LIBRARY HALF IS STILL OPEN, and I nearly missed it by assuming.** After setting Precise I
+> reasoned the cross-platform risk was gone. It is not:
+>
+> **`sinf`/`cosf` are not specified by IEEE-754.** MSVC's CRT and glibc's libm may legitimately
+> return different results (typically ≤ 1 ULP). And `FMath::Sin`/`FMath::Cos` are used throughout the
+> density path — layer lines (`VoxelGenerator.cpp:2275`, `VoxelHeightOpStack.cpp:232`), ribs (`:1357`),
+> room placement (`:1520`), rotations (`:362`, `:408`, `:1663`). So a Windows host and a Linux client
+> can still disagree, just by ~1 ULP instead of by a whole reassociation.
+>
+> **Measured, not assumed:** `CrossPlatformDigest` now reports a *profile* — samples within 1e-4 /
+> 1e-5 / 1e-6 of the isosurface. Only the tight band matters (a libm delta is ~1e-6 absolute on
+> densities of magnitude ~10), and the first run showed **2 / 115 000 within 1e-4** — i.e. the wide
+> band, which over-states the risk by ~100×. The tight-band number is the one to watch.
+>
+> **If it must be zero:** a deterministic in-house `sin`/`cos` in the density path (a polynomial with
+> defined rounding), which costs one more world re-tune. **Not another build flag** — no compiler
+> setting can make two different libm implementations agree.
 
 Found while chasing a 1-ULP difference between `GetMazeDensity` and its operator-stack port. The
 difference survived a full bisect down to code that is character-for-character identical, which