Adopt per-release deploy snapshots (src/generated/<tag>/) via the shared LibSnapshot

## Ask

Every repo that deploys needs a **per-release snapshot of its deployment record** — at minimum the Zoltu address, creation bytecode, runtime bytecode and codehash — generated (not hand-written) and frozen under `src/generated//`, one dir per published release.

This repo deploys and carries **hardcoded deploy constants** today, with no per-release record.

## Why hardcoded pins are not enough

A hand-maintained address/codehash/creation-code literal is a second source of truth: nothing generates it, so nothing enforces that it still matches the code. The usual guard — a `testDeployAddress` / `testExpectedCodeHash` / `testExpectedCreationCode` trio — proves only that **today's build agrees with today's constants**. It says nothing about the releases already published, which is the thing consumers actually pin against.

Without a frozen per-release record:
- **No published release can be reproduced or independently verified** once the current build diverges.
- A consumer of an older release has no way to get that release's addresses.
- The single "current" pin collides with **every bytecode-changing PR** — the prod-deploy test goes red until a redeploy (the premerge chicken-and-egg).

Zoltu addresses are a pure function of creation code, so the whole record is **computable offline** — this needs no network, no registry, and no skips.

## How

Use the shared **`LibSnapshot`** from `rain-sol-codegen` (published in **0.1.1**) — do NOT hand-roll a copy (that is how the canon ended up copy-pasted across four repos with the safety guard in only half):

- `LibSnapshot.deployTag(vm)` — `[package].version` with dots→underscores.
- `LibSnapshot.freezeSnapshot(vm, contractNames)` — freezes the generated pointers into `src/generated//`, **reverting** rather than rewriting a frozen record without a version bump.
- Add `{ access = "read", path = "foundry.toml" }` to `fs_permissions` (needed by `deployTag`).
- Verify with a deterministic, offline test that re-derives the record and asserts no drift.

**Reference implementation: rainlanguage/rain.math.float#253** — same migration end to end (generate the record via a locally etched Zoltu factory, freeze per tag, retire the hand-pinned literals into their snapshot, keep the public constant names as aliases so consumers do not break).

## Related

- rainlanguage/rain.sol.codegen#25 / #26 — `LibSnapshot` upstreamed.
- rainlanguage/rainix#271 — the complementary "every published version has its snapshot" check, in shared CI.
- rainlanguage/claude-audit-skills#46 — the audit skill now flags exactly this gap (HIGH).

## This repo specifically

It has **no `script/BuildPointers.sol`** — there is no pointer generation at all today, so the deploy constants are pure hand-maintained literals. This is therefore the larger shape of the migration: introduce the codegen script first (deploy through a locally etched Zoltu factory, capture address + codehash + creation + runtime bytecode via `LibFs`/`LibCodeGen` from `rain-sol-codegen`), then freeze it per tag with `LibSnapshot.freezeSnapshot`.

The existing hardcoded constants should end up **generated and aliased**, not deleted — keep the public constant names stable so consumers do not break, exactly as rain.math.float#253 does.

First step is a check, not a change: regenerate and confirm the generated record **reproduces the existing hardcoded literals byte for byte**. If it does, the pins were right and the migration is safe. If it does not, that discrepancy is itself a finding — surface it rather than committing over it.