spec-guards: ring-096 and specs/numeric/formats.t27 DRIFTED -- both sides disagree with the gf16 SSOT on f32 #6887

What is wrong

spec-guards is red on master and on every pull request that touches specs/** or rings/**. The failing step is python3 tools/check_ring_spec_drift.py, which exits 1 on one pair:

DRIFTED  ring-096-rust  specs/numeric/formats.t27
         hand fns 7, spec fns 6, shared 6, differing 5:
         f32_to_gf16, f32_to_ternary, gf16_to_f32, quantize_value, ternary_to_f32

Example: https://github.com/gHashTag/t27/actions/runs/37473887427/job/112304143768

Cause

Both files were written in the same commit (ea15cd5, #1399) and never agreed:

The drift was invisible until 2026-09-17: the spec declared its functions as fn sig;, which does not parse, so gen-rust emitted nothing and the pair read UNRELATED. #4248 made the declarations fn sig { }, the spec started generating, format_bytes matched and the other five did not, and the pair became DRIFTED.

Both sides are wrong, against the SSOT (law L6):

• Spec: a decoder named gf16_to_f32 returning gf16 (which lowers to u16) contradicts gf16_decode_to_f32 ... f32 in gf16.t27. Same for ternary_to_f32 and for quantize_value, whose own tests read the result back as a float near 1.5.
• Ring: the hand crate uses f64 where the spec and the SSOT both say f32, while its header claims it "mirrors specs/numeric/formats.t27 byte-for-byte".

Fix (one PR)

• specs/numeric/formats.t27: the three return types become f32; the tests and invariants that wrapped those results in gf16.to_f64(...) compare the f32 directly. Two false claims in the same tests are corrected rather than carried: 0x3C00 is not 1.0 under bias 31 (it is 0x3E00; the ring's test already says so), and ternary_to_f32_is_inverse listed -0.5 and 0.5, which quantize to 0 under the strict threshold. Resealed.
• rings/ring-096-rust/src/lib.rs: the public API moves to f32. The f64 arithmetic stays as private helpers; narrowing at the boundary is exact because every GF16 value is representable in f32 and f32 -> f64 is exact. All 42 crate tests pass (rustc 1.99 on the t27c Railway lab).
• specs/numeric/formats.t27: ExpShift / SignShift change from u5 / u4 to u8, matching EXP_SHIFT / SIGN_SHIFT in gf16.t27. gen-rust passed u5/u4 through verbatim, so the generated Rust did not compile and the differential harness could not even be built. Resealed again.

Editing the existing Rust in rings/ring-096-rust/src/lib.rs is an exception to "Only t27"; this issue carries the label owner-approved-foreign under the owner's standing rule of 2026-10-06, and the path is listed in tools/policy/foreign-exceptions.txt for this issue only.

Known follow-up, not hidden (measured)

After the fix the pair is CONVERGED, so the differential step runs it. On the lab it prints covered 2 of 6, REFUSED 4 (Trit/Format have no producer) and exits 2. That is an honest "could not test": the spec functions have no bodies (unimplemented!()). Tracked in #6893. On master that step is not reached anyway, because tools/published_figures.py --check fails earlier in the same job with 8 drifted figures, independent of this pair.

Refs #6488