fix(gen): untrack stale gen/numeric catalog artifacts (drift 77 vs SSOT 83)

The committed gen/numeric codegen artifacts are a pre-correction snapshot
that drifts against the SSOT (declares 77 vs SSOT 83, plus a gf128 e/m typo
correction). Per the repo constitution (L2 GENERATION), gen/ is DERIVED and
never hand-committed (gen/ is gitignored; the count gate regenerates into a
temp dir). These 16 files were historically force-added, which is the only
reason they can drift. Remove them from tracking (deletions only, no gen/
modifications) so a fresh codegen run is their single source.

Nothing reads the committed gen/numeric/formats_catalog.json at build/test/CI
time. Verified locally via an independent Rust SSOT-vs-gen oracle: stale file
DIVERGENCE (exit 2), fresh regen CLEAN (exit 0, SSOT == gen == 83).

Closes #1120

Author: Dmitrii Vasilev

docs/NOW.md

@@ -30,6 +30,13 @@ Last updated: 2026-06-14
 - **Why** this closes the last mile of the seal workflow without weakening the honest-by-design model: regeneration still goes through `nmse_gf16.py --seal`, which only seals when the live compiler hashes to FROZEN_HASH (`compute_seal()` never fabricates), so the script makes resealing one-command and auditable but NOT automatic. Not wired into CI; never run by any required check. Verified: the no-TTY, env-not-set, and typed-not-`yes` paths all abort with FROZEN_HASH and the manifest byte-for-byte unchanged (confirmed via sha256 before/after). L6 gf16 SSOT untouched; catalog stays 83; no gen/ edits; ASCII-only added lines; no quality claim added. Closes #1117.
 - **Anchor**: phi^2 + phi^-2 = 3
 
+## untrack-stale-gen-numeric-catalog -- remove the committed gen/numeric catalog artifacts that drift against the SSOT (Closes #1120)
+
+- **WHERE**: deletes the 16 tracked codegen artifacts under `gen/numeric/` (formats_catalog.{md,json,py,rs,h,hpp,ts,go,zig,swift,kt,vh,ml} + FormatsCatalog.{hs,java,jl}). No spec, tool, or test file is changed.
+- **WHAT**: issue #1120 reported that the committed `gen/numeric/formats_catalog.json` declared 77 formats while the SSOT `specs/numeric/formats_catalog.t27` carries 83 (`grep -c '// CATALOG:'` == 83 on this HEAD), a delta of 6 (the GoldenFloat rungs gf10/gf14/gf48/gf96/gf512/gf1024) plus 15 field mismatches, including a substantive numeric one: gf128 stored e_bits=48/m_bits=79 in the stale committed file vs the SSOT-correct e_bits=49/m_bits=78 (the SSOT line annotates "corrects v1.1 typo e=48"). Root cause: the committed artifacts are a pre-correction codegen snapshot that was never refreshed, and the repo constitution (L2 GENERATION) treats `gen/` as DERIVED and never hand-committed -- `gen/` is in `.gitignore` (line 6), and the catalog-count gate regenerates fresh into a temp dir rather than diffing the committed file. The 16 artifacts were historically force-added into tracking, which is the only reason they can drift at all. This PR removes them from tracking (status D, which the L2 gate permits -- it blocks only M under gen/). After this change, a fresh `python3 tools/gen_formats_catalog.py specs/numeric/formats_catalog.t27 <out>` is the single source of these files, so the 83-vs-77 drift class can no longer exist.
+- **Why** nothing reads the committed `gen/numeric/formats_catalog.json` at build, test, or CI time (only the codegen tool references its own output path in a comment), so deleting it is non-breaking; and an independent second-implementation diff (a from-scratch Rust SSOT-vs-gen oracle, run locally) confirmed DIVERGENCE on the stale committed file (exit 2) and CLEAN on a fresh regen (exit 0, SSOT == gen == 83, gf128 e=49/m=78), proving the drift was real and that regeneration resolves it. L6 gf16 SSOT untouched; catalog stays 83; no gen/ edits (deletions only); ASCII-only added lines; no quality claim added. Closes #1120.
+- **Anchor**: phi^2 + phi^-2 = 3
+
 
 ## warnings-baseline-meter -- advisory non-test build-warning meter for the #969 audit (Closes #1116)