Migrate deploy constants to the per-version snapshot canon (src/generated/<tag>/), retiring the flat *_0_1_1 model + its FFI/registry test

[thedavidmeister]

Problem

rain.math.float is on the outdated deploy-constants model and needs to come up to canon with per-version snapshots.

Today: src/lib/deploy/LibDecimalFloatDeploy.sol carries flat, version-suffixed constant families — four per release (ZOLTU_DEPLOYED_LOG_TABLES_ADDRESS_0_1_1, LOG_TABLES_DATA_CONTRACT_HASH_0_1_1, ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS_0_1_1, DECIMAL_FLOAT_CONTRACT_HASH_0_1_1) alongside the unsuffixed "current" set. Completeness is policed by script/check-published-deploy-constants.sh, which curls the soldeer registry and is invoked over FFI by test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol.

Canon (as in raindex, rain.factory, st0x.deploy): frozen per-version snapshots under src/generated/<tag>/, written by BuildPointers from foundry.toml [package].version, verified locally, and policed for immutability by rainix's existing frozen-snapshots-append-only action.

Why this is broken now, not just untidy

1. The two rainix gates contradict each other under the old model. The registry check needs a network-tolerance escape hatch (SKIP: → vm.skip(true)), and rainix's no-ignored-tests gate bans exactly that ("a test either runs and passes, or it is deleted"). main is currently red on rs-static + rainix-sol / static for LibDecimalFloatDeployTaggedConstants.t.sol:24. Removing the vm.skip doesn't help — an early return still means the test silently verifies nothing offline. A forge unit test cannot verify remote state.
2. It already failed. soldeer has 0.1.7 published (2026-07-14T18:54:19Z) while the lib pins only _0_1_1. Published {0.1.1, 0.1.7} vs pinned {0.1.1} → the invariant is live-violated and the test now reds with MISSING: *_0_1_7. (The publish fired from a markdown-only merge, which is worth its own look.)
3. No local source of truth exists for "which versions are published": no changelog/manifest; soldeer.lock/foundry.lock record dependencies only; git tags don't map (published 0.1.1 → tag v0.1.1 but published 0.1.7 → sol-v0.1.7; five sol-v0.1.2…sol-v0.1.6 tags were never published; the v* namespace is polluted by crate/npm tags). Snapshots fix this by making the committed src/generated/<tag>/ dirs themselves the local record.

Scope

• script/BuildPointers.sol — add deployTag() (parse foundry.toml [package].version, dots→underscores) and freezeSnapshot() writing src/generated/<tag>/, with the immutability guard (rewriting an existing snapshot with different content must revert, telling the author to bump [package].version). Mirror raindex's implementation. Requires adding foundry.toml read to fs_permissions.
• src/generated/<tag>/ — create snapshots for each published version, rebuilt byte-faithfully from that version's tag (not hand-written):
  • 0_1_1 — log tables 0xc51a1425… / 0x2573004a…, DecimalFloat 0xBee0eEFa… / 0x7a93d031…
  • 0_1_7 — verified byte-identical at tag sol-v0.1.7 to the current unsuffixed values: log tables 0xc51a1425… / 0x2573004a…, DecimalFloat 0x799632d2… / 0xdc468883…
• test/src/lib/deploy/LibDecimalFloatDeployTaggedConstants.t.sol — replace the FFI/registry test with network-free per-snapshot verification (each snapshot's codehash matches its runtime code; the Zoltu deploy reproduces the pinned address). No FFI, no network, no skip path — it always runs and passes or fails.
• Delete script/check-published-deploy-constants.sh (its job moves to rainix — see below).
• LibDecimalFloatDeploy.sol — retire the flat *_0_1_1 families in favour of the snapshot imports, keeping the current unsuffixed constants as the live release's source.

Out of scope / related

• Upstream the 'every published soldeer version has its frozen snapshot' check to rainix rainix#271 — upstreams the "every published soldeer version has its snapshot" check to shared CI (ideally as a publish-time gate in rainix-autopublish, which deterministically knows the version being published). The two land together: this issue deletes the hand-rolled script, that issue replaces its enforcement.
• Prod-deploy gap — testProdDeployment{Arbitrum,Base,BaseSepolia,Flare,Polygon} red with "DecimalFloat not deployed": the current bytecode isn't deployed on any prod network. That needs a per-network Zoltu deploy, not a code change, and is tracked with the existing blocked-deploy work (fix: guard mul() exponent-sum overflow, surface as ExponentOverflow #244/Guard displayExponent overflow in _toScientific (#185) #245).