integrity-gate: gf16, gf10 and gf256 vector packs do not match their INDEX digests #7457

The integrity-gate check (WP-18, tools/wp18_conformance_gate.py, check C) is red on master: the files gf16_conformance_v0.json, gf10_conformance_v0.json and gf256_conformance_v0.json no longer hash to the sha256 recorded for them in conformance/vectors/INDEX_all_formats.json. Every PR inherits the red.

Where it came from:

• b5b852f (Five more confirmed defects in the required merge contexts #4730) rewrote the bare Infinity/-Infinity floats in the gf16 pack as strings so the file is strict JSON. The bit patterns and the decoded_f64_hex values did not change. The INDEX sha was not updated.
• e91cb7e ([conformance] Promote gf10 and gf256 to bitexact_selfconsistent (WP-34) #4763) hand-edited the prose format_notes of gf10 (a pack gen_all_formats.py generates, so the next regeneration silently reverts it) and changed gf256's prose and status Conj -> Open (matching the catalog row, status=Open). The INDEX sha was not updated for either.

Which side is right: the values. L6 says FORMAT-SPEC-001.json and specs/numeric/gf16.t27 are the numeric SSOT. All 21 gf16 rows decode, under gf16.t27's S1E6M9 layout with bias 31, to exactly their recorded decoded_f64_hex, and every WP-18 value check (D, D2, G and the rest) already passes on master. Only the recorded digests are stale.

Fix: regenerate with conformance/vectors/gen_all_formats.py from the committed SSOT instead of editing hashes by hand. That brings back gf10's generated prose, records the new gf16 and gf256 digests, and refreshes tnf16's catalog phi_distance 0.086 -> 0.0417 (the catalog row changed in 2e4093d, #4795, without a regeneration). After it, the WP-18 gate prints CLEAN.