Track the #242 consumer migration: 7 repos, 17 candidates, 2 that #242 cannot express

[thedavidmeister]

Tracking issue for the consumer migration that #242 forces.

#242 removes DeployCandidate.sourceCreationCode and makes
checkCandidatesAnchoredToSource resolve the candidate's own
snapshot.artifactPath through vm.getCode instead, so the anchor's source
operand comes from the compiler rather than from the declaration. Its "Consumer
migration — BREAKING" section is the spec; this issue tracks who has to do it and
what it costs each of them.

#242 is open, unmerged and unreleased. There is no published rain-deploy
version carrying this change, so none of the linked issues names a bump target.
Each says so explicitly rather than inventing one.

Consumer issues

Repo	Pin today	Candidates	Issue
raindex	0.1.10	6 (1 blocked)	rainlanguage/raindex#2883
rainlang.deploy	0.1.10	5	rainlanguage/rainlang.deploy#8
rain.math.float.deploy	0.1.10	2 (1 blocked)	rainlanguage/rain.math.float.deploy#27
rain.factory.deploy	0.1.8	1	rainlanguage/rain.factory.deploy#44
rain.metadata.deploy	0.1.8	1	rainlanguage/rain.metadata.deploy#13
rain.tofu.erc20-decimals.deploy	0.1.8	1	rainlanguage/rain.tofu.erc20-decimals.deploy#8
rain.extrospection.deploy	0.1.7	1	rainlanguage/rain.extrospection.deploy#10

17 DeployCandidate literals across 7 repos, plus each repo's script/Build.sol
regenerateSnapshots call and, in two repos, local tests that read the removed
field.

Two candidates cannot be expressed under #242 as written

This is the finding worth acting on before #242 merges. Both of these are
legitimate candidates whose source is not a compiler artifact, and the anchor
now runs over every candidate with no way to spell an exemption:

• raindex, suite route-processor —
  artifactPath: "RouteProcessor4", a bare contract name, with
  sourceCreationCode a vendored hex literal in
  src/lib/deploy/LibRouteProcessor4CreationCode.sol taken from sushiswap's
  published deployment. There is no local Solidity source.
  raindex's test/script/Build.t.sol already documents the bare-name form as
  the convention for "a suite with no local Solidity source".
• rain.math.float.deploy, suite log-tables — artifactPath: "", with
  sourceCreationCode the expression
  LibDataContract.contractCreationCode(LibDecimalFloatDeploy.combinedTables()).
  It is a data contract assembled from src/generated/LogTables.pointers.sol;
  the declaration's own doc says the path is empty because there is no source
  file for an explorer to verify against.

For both, vm.getCode has nothing to resolve, so checkCandidatesAnchoredToSource
fails — and it fails inside RainDeployBroadcast.run() before the broadcast, not
only in CI. script/Build.sol's regenerateSnapshots is blocked the same way,
since #242 changes it to write from the same vm.getCode call.

#242's migration text assumes every candidate's source is a compiler artifact.
Two of the seven consumers have one that is not, so this needs an answer here
before a release, not a workaround in each consumer. Directions, none chosen:

1. a documented way for a candidate to declare a derived or vendored source that
   the anchor honours — the hard part being that it must not become an exemption
   a consumer can spell for an ordinary contract, which is the property fix: read the candidate source anchor from the compiler, not the declaration #242
   exists to establish;
2. requiring such suites to emit a real artifact so artifactPath resolves;
3. requiring them out of the candidate set, anchored by some other check.

Not affected

Migration item 3 ("any consumer wrapper marked pure must become view") turns
out to need no edit in any consumer: all seven inherit RainDeployVerifySnapshot
without redeclaring testSnapshotMatchesSource or wrapping
checkCandidatesAnchoredToSource, so that mutability change lands entirely
inside this package. Item 4 (no foundry.toml change) holds.

Eight further repos depend on rain-deploy but declare no candidates and need no
edit for this change: rain.dia, rain.erc4626.words, rain.flare, rainlang,
rain.merkle, rain.pyth, rain.verify — they use LibRainDeploy or pull the
package transitively — and this repo itself, which #242 edits directly.

How the consumer list was enumerated

GitHub code search is not reliable for this org: searching sourceCreationCode
and DeployCandidate under org:rainlanguage returned only raindex, missing
this repo and all six other consumers. The list above was built instead by
fetching foundry.toml, remappings.txt and soldeer.lock from the default
branch of all 119 non-archived org repos and grepping for rain-deploy — run
twice, once over raw.githubusercontent.com and once over the GitHub contents
API, with both passes agreeing on the same 15 repos. Each of those 15 was then
cloned and searched for actual DeployCandidate literals, which is what
separates the 7 consumers above from the 8 that only depend on the package.
Every artifactPath in all 17 literals was checked against its repo's tree; the
two named in the blocker section are the only ones that do not resolve.