Migrate deploy records to src/generated/<tag>/ so release-guard works here

[thedavidmeister]

rain.math.float.deploy pins its deploy records as hand-written constants inside
src/lib/deploy/LibDecimalFloatDeploy.sol — ZOLTU_DEPLOYED_DECIMAL_FLOAT_ADDRESS,
DECIMAL_FLOAT_CONTRACT_HASH, and a *_0_1_7 set per published version. Every other
deploy repo in the org now carries a rolling src/generated/candidate/ plus one frozen
src/generated/<tag>/ per release, generated by script/Build.sol on rain-deploy's
BuildScript.

Migrate this repo to that model.

Why, concretely

release-guard cannot see hand-written constants. rainix's publish guard runs
immediately before forge soldeer push and fails closed unless the tagged commit carries:
the version matching the tag, src/generated/<version>/ present, no larger tag already
frozen, and that snapshot byte-identical to a fresh regeneration. All four are checks on
src/generated/<tag>/. A repo whose records live in a Solidity constant gets none of them.

So this repo grew a substitute. script/check-published-deploy-constants.sh queries
api.soldeer.xyz over FFI and asserts each published version has its constant suite —
about 200 lines of bash plus fixtures plus an FFI test, doing by hand what release-guard
does generically. #3 has just spent a full round hardening it (a SKIP that swallowed both
transport failure and unparseable responses, retiring the registry half while every run
stayed green). That is maintenance paid on a scheme the org has moved off.

A second source of truth. Nothing generates the constants, so nothing enforces that
they still match the code. The usual guard — testDeployAddress / testExpectedCodeHash —
proves only that today's build agrees with today's constants, and says nothing about
versions already published.

What migrating buys

• release-guard starts working here, replacing the bespoke check.
• frozen-snapshots-append-only starts working here — it is a presence test on
  src/generated/, so a repo without that directory is skipped entirely today.
• script/check-published-deploy-constants.sh, its three fixtures and its FFI test can go.
• The release becomes the same two-step every other deploy repo uses: a PR freezing
  src/generated/<tag>/ in lockstep with the version, then a sol-v* tag on the merge
  commit.

Scope

Deployment and release machinery only. Do not restructure src/, do not move library code,
do not touch crates/, the npm surface, or the subgraph.

The worked precedents, all of which released today or are ready to: rain.factory.deploy
(released 0.1.10), rain.tofu.erc20-decimals.deploy (released 0.1.0),
rain.metadata.deploy (released 0.1.0). rain-deploy is at 0.1.7; this repo's
script/Build.sol predates BuildScript.

No historicals

Do not port the existing *_0_1_7 constants forward as frozen src/generated/ dirs.
Migrations carry the current shape forward only; consumers have git and the published
Soldeer revisions. The first release under the new model freezes its own tag and nothing
before it.

This mirrors the ruling applied when rain.metadata.deploy was built.

Ordering, and what this does not fix

main is red for reasons this migration does not address, and they should not be folded in:

• fix(test): drop vm.skip from the tagged deploy constants check #3 (drops the vm.skip that fails no-ignored-tests) and style(docs): deno fmt CLAUDE.md and README.md #6 (the denofmt failure fix(test): drop vm.skip from the tagged deploy constants check #3
  uncovers) are the PRs that green static. fix(test): drop vm.skip from the tagged deploy constants check #3 hardens the very script this migration
  deletes. Decide deliberately whether fix(test): drop vm.skip from the tagged deploy constants check #3 still lands first or is superseded — do not
  leave both paths half-done.
• rainix-sol / test fails on LibDecimalFloatDeployProdTest. As of 2026-08-21
  DecimalFloat is deployed on five of seven networks — ethereum, arbitrum, base,
  base_sepolia, flare — and absent on polygon and hyperevm. HyperEVM rejected it at
  ~6M gas against a 3M small-block limit; polygon simply sits after hyperevm in the
  broadcast order and was never reached. That is a deployment task, not a migration one.

Open question worth answering while in here

rainix checks only the version being released. Nothing sweeps the registry to assert every
already-published version still has a record in the tree — a different property, and the
one this repo's bash check was reaching for. rain.factory.deploy's 39d1cfd deleted three
frozen snapshots while CI reported success, so the gap is real.

If that check is worth keeping, it belongs in rainix-static over src/generated/, not in
per-repo bash over constant names. Say whether you think it should be filed against rainix
rather than reimplementing it here.