Audit rain.erc end-to-end

[thedavidmeister]

`rain.erc` has had two non-trivial refactors land back to back:

• PR Drop alloy-ethers-typecast, use upstream alloy directly #19 — drop `alloy-ethers-typecast`, switch to upstream alloy `Provider` + inline `sol!`.
• PR Distinguish execution reverts from other errors in ERC-165 probe #20 — distinguish execution reverts from transport / decode failures in the ERC-165 probe (`Result<bool, Erc165Error>`).

Plus pending cleanup work in #21 (drop `lib/forge-std`), #22 (README), #23 (CLAUDE.md).

A focused audit pass while the surface area is small and the changes are recent will catch things before downstream consumers (rain.metadata, others) bump the rev.

Coverage to walk

1. Process / repo hygiene — pinning, CI shape (Rainix CI is the only check), missing CLAUDE.md (Initialise Claude Code memory (CLAUDE.md) in this repo #23), README staleness (Update README to reflect Rust-only crate #22).
2. Test coverage — `is_revert_like`, both ERC-165 checks, the propagation paths, `xor_selectors` branches. Identify any uncovered branches and propose mutation-verifiable tests.
3. Documentation accuracy — rustdoc on public items vs actual behavior (PR Distinguish execution reverts from other errors in ERC-165 probe #20 review surfaced one already; sweep for similar drift).
4. Code quality — leaky abstractions, naming (`is_revert_like` is fine; check for any `Helpers` / `Utils` shapes), commented-out code, build warnings.
5. Security / correctness — does the ERC-165 probe match the spec exactly under all branches? Are there RPC error variants we should also fold into Ok(false)? Is the wasm dep tree (Drop alloy-ethers-typecast, use upstream alloy directly #19's getrandom workaround) sound?
6. Hazard surface — what footguns does `Erc165Error::Call` expose? Is `alloy::contract::Error` re-exposed in our public API surface in a way that ties us to alloy's ABI?

`/audit` skill in Claude Code can drive this in passes once #23 lands and CLAUDE.md exists for the audit context.