Split deploy half out of rain.flare (rainix#296) #207

Part of the org-wide repo refactor tracked in rainlanguage/rainix#296.

What

Split this repo into a library half (stays here, autopublishes to Soldeer on merge via rainix-autopublish) and a deploy half (new rain.flare.deploy repo, releases only on a manual sol-v* tag via rainix-tag-release). Every repo must end up strictly one or the other, never both.

Why this repo

Carries both halves: 2 deploy artifacts, 1 concrete contract.

Two independent problems, both of which the split is relevant to:

1. Release lane wedged — [package].version is 0.1.2 and the published rain-flare revision is also 0.1.2, so the next-version invariant rejects every run.
2. startup_failure — the Package Release run never creates a job, because the caller declares no permissions: block while the repo default is read. Fix open as fix(ci): grant Package Release the token permissions its callee needs #206. That is unrelated to the split, but it means this repo's lane will still be wedged once the workflow starts.

Method

Follow the precedent set by rainlanguage/rain.factory#46, which verified the cut was clean before moving anything:

1. Confirm the cut is one-way — interfaces import nothing concrete, concrete imports the interfaces, the deploy-pin lib is isolated. A clean cut is what makes the rest mechanical.
2. Create the .deploy repo with the concrete contracts, the deploy-pin lib, the frozen src/generated/<tag>/ snapshots, script/Deploy.sol and script/BuildPointers.sol, plus rainix-tag-release CI. It depends on this repo's Soldeer package.
3. Release the .deploy repo so its pins publish. Requires a human: the on-chain deploy is a manual dispatch, and the tag is cut by hand.
4. Slim this repo to the library half.
5. Migrate any consumer importing the deploy pins.

Steps 1, 2 and 4 are authorable now. Soldeer revisions are immutable and this org carries the version inside the import path, so existing consumers stay pinned to working revisions throughout and only move when someone deliberately bumps — at which point a mistake is a compile error, never a silent resolution.

Done when

• Cut verified one-way
• .deploy repo created with the deploy half
• .deploy repo released, pins published
• This repo slimmed to the library half
• Deploy-pin consumers migrated
• This repo's release lane publishes cleanly