Add the orchestrator beacon to the governed beacon set

[thedavidmeister]

Closes #333. Stacked on #325.

The gap

prodBeaconsForChainId returned three beacons. Production has four. The fourth is the orchestrator beacon, and after #324 it holds mint/burn authority over the other three — so the most governance-sensitive beacon in the system was the one surface 20260729-migrate-governance-to-timelock could never reach, because it walks that array.

Nothing failed. GovernanceTimelockMigration.t.sol only checks the enumerated three, so it stayed green while the orchestrator beacon sat outside the migration entirely. Left alone past the 2026-10-01 deadline it is stranded, upgradable by whoever owns it, while every other beacon moves under the timelock.

What changed

• LibProdBeaconsBase / LibProdBeacons0_1_1: beacons() and implementations() widened to address[4], orchestrator beacon and its impl appended so existing indices hold.
• LibBeaconInvariants: ORCHESTRATOR_BEACON_INDEX = 3 beside the three constants Fleet upgrade bundle: receipt + receipt-vault beacons to audited 0.1.30 #325 added; prodBeaconsForChainId returns address[4].
• prodBeaconCodehashesForChainId, new and index-aligned. The set now spans two build generations: the token beacons are the V1 build (858 bytes, 0x8e95867e…), the orchestrator beacon is OZ 5.6.1 at the current optimizer_runs (728 bytes, 0x448cd063…). A single pin reverts on it. Both _assertDeployedPinnedBeacon and _selectBeaconTargets in the timelock migration hardcoded one constant; both now take the per-beacon value.
• Consumers that iterate are otherwise unchanged — they pick the fourth member up for free.
• MigrateBeaconOwners deliberately keeps its own three-element list: it is a historical executed script with its own literals, not a consumer of this accessor.

Sequencing — this needs #317 broadcast first

The orchestrator beacon is still owned by the deploy EOA 0x8E4bdeec… on all three chains; #317 transfers it to the chain Safe and has not been run. Until it is, assertProdBeaconsOwnedByChainSafe fails on the new member, because it requires one owner across the set.

That is sequencing, not a code gap, and it is verified rather than assumed. Simulating #317 - a single transferOwnership pranked from the EOA - then asserting the widened set:

[PASS] testBaseAfter317()
[PASS] testEthereumAfter317()
[PASS] testHyperEvmAfter317()

Draft until #317 has been broadcast on Base, Ethereum and HyperEVM.

QA

• Discriminating tests: the existing suite is the discriminator here, and it fails loudly on the base commit in exactly two groups. Before the codehash change: testRunAuthorsFullMigration, testRunAuthorsFullMigrationOnEthereum, testRunAuthorsFullMigrationOnHyperevm, testGovernanceCanMigrateAwayToSuccessor, testVerifyAcceptsAuthoredArtifactAndRejectsTamper all die with MigrationBeaconCodehashMismatch(0xb9DCd744…, 0x8e95867e…, 0x448cd063…). After it, all five pass. The remaining 8 failures are the owner precondition above, cleared by Orchestrator beacon-owner migration to the chain Safe #317 and demonstrated by the pranked-transfer run.
• Mutations applied: prodBeaconCodehashesForChainId -> return UPGRADEABLE_BEACON_CODEHASH in all four slots -> the five migration tests above die again with the same selector. _selectBeaconTargets -> revert expectedCodehashes[i] to the single constant -> same five die. Appending vs inserting the new member was checked by keeping RECEIPT_BEACON_INDEX/RECEIPT_VAULT_BEACON_INDEX at 0/1 and confirming Fleet upgrade bundle: receipt + receipt-vault beacons to audited 0.1.30 #325`s fleet tests still pass.
• Oracle: live chain state, independent of this code. The orchestrator beacon 0xb9DCd744b0413Dff0EDC70A5B229c7aa03734613 carries 728 bytes on Base, Ethereum and HyperEVM; the V1 fleet beacon 0x86e93c39… carries 858 on Base. Its owner reads 0x8E4bdeec… (the deploy EOA) on all three, and the V1 beacons read 0xe70d821f… (the token-owner Safe) — which is why the set is not uniform until Orchestrator beacon-owner migration to the chain Safe #317 runs.
• Category check: Orchestrator beacon owner is pinned to the hot deploy EOA as permanent expected state, and the timelock migration structurally cannot reach it #333 asks for one thing — the orchestrator beacon must be in the set the governance-timelock migration walks. Covered, plus the per-beacon codehash the widening turned out to require, which Orchestrator beacon owner is pinned to the hot deploy EOA as permanent expected state, and the timelock migration structurally cannot reach it #333 records as part of the same job.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 83f00c06-e5b7-4e35-8dcd-9cf23d7428ba

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[hardyjosh]

Warning

This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

• Retire bundle: signer's direct vault roles, after the burn-in #336
• Add the orchestrator beacon to the governed beacon set #334 👈 (View in Graphite)
• Fleet upgrade bundle: receipt + receipt-vault beacons to audited 0.1.30 #325
• Cutover bundle: mint/burn to the orchestrator, signer via MINT/BURN #324
• Orchestrator beacon-owner migration to the chain Safe #317
• Orchestrator instance deploy script + pinned invariants #316
• Deploy workflow for the audited 0.1.30 orchestrator set #314
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.