Convert BuildPointers to the shared LibSnapshot — and gain the missing immutability guard

[thedavidmeister]

Context

LibSnapshot now owns the per-release snapshot canon in rain-sol-codegen (rainlanguage/rain.sol.codegen#26, closing #25): deployTag(vm) and freezeSnapshot(vm, contractNames), with the immutability guard that reverts rather than rewrite a frozen record without a [package].version bump.

It was upstreamed because the canon was copy-pasted across four repos and had already diverged — deployTag() byte-identical in three, the freezing half in three different shapes, and the guard present in only half of them.

The change

script/BuildPointers.sol in this repo carries its own copy. Replace it:

1. Import LibSnapshot from rain-sol-codegen (this repo already depends on the package — BuildPointers.sol imports LibFs/LibCodeGen from it).
2. Delete the local deployTag() / freezing code.
3. Call LibSnapshot.freezeSnapshot(vm, names) with the generated contract names.
4. Ensure foundry.toml fs_permissions grants { access = "read", path = "foundry.toml" } (needed by deployTag).

Verification

Regenerating must be a no-op against the existing committed snapshots — same tag dir, byte-identical files. If anything changes, that is a real finding, not a formatting difference: stop and surface it rather than committing the diff.

Blocked on

rain-sol-codegen needs a version bump + publish — LibSnapshot is on main but the published package is still 0.1.0, so there is nothing to import yet.

This repo specifically — this one is not purely cosmetic

This repo has deployTag() but no freezeSnapshot() and no immutability guard: it inlines a bare vm.createDir(string.concat("src/generated/", deployTag()), true). So regenerating over an existing tag silently rewrites the frozen deployment record that consumers of that published release pin against. rainix's frozen-snapshots-append-only action catches it in CI, but that is catching after the fact what the generator should refuse outright — and only the local guard gives the actionable message ("bump [package].version for a new release") at the moment it matters.

Converting therefore adds a real safety property, and is a deliberate behaviour change: a regeneration that would alter one of the 3 existing tag dirs will now revert instead of silently succeeding. If that revert fires during conversion, it has found a pre-existing corruption — surface it, do not force past it.