fix(L1): retarget the AggregateVerifier cadence switch to Denim

[0xth4nh]

Reverts the fork target introduced in #431 (merged). The 200ms block-time hardfork moved back to Denim.

What changed?

• FAST_BLOCK_UPGRADE_INDEX in AggregateVerifier: 12 (Cobalt) → 13 (Denim).
• Test-local FAST_BLOCK_UPGRADE_INDEX in AggregateVerifier.t.sol follows it. Every test references the constant symbolically, so no fixture arithmetic changed.
• snapshots/semver-lock.json regenerated — only the AggregateVerifier entry moves.
• Semver stays at 0.2.0. Nothing has consumed 0.2.0 yet — it was introduced by feat(L1): fork-gate AggregateVerifier proposal intervals for Cobalt #431 and no deployment reads it — so there is no version anyone could be pinned to and nothing to bump away from.

No machinery changed. _firstFastBlock(), _l2Timestamp(), and _intervalsAt() are unchanged; only the index they read is different.

Why?

The switch to Cobalt in #431 was made on the reasoning that the Base mainnet schedule is 13 entries long (indices 0–12) and could therefore never reach index 13. That is true today but it isn't a constraint — _timestamps is a dynamic array and registerUpgrade extends it, which is exactly how Denim gets its entry.

Both indices fail open in the same way and for the same duration:

• Index 12 (Cobalt) exists today with a zero timestamp. _firstFastBlock() hits if (fastActivationTimestamp == 0) return type(uint256).max.
• Index 13 (Denim) is one past the end. _firstFastBlock() hits if (schedule.length <= FAST_BLOCK_UPGRADE_INDEX) return type(uint256).max.

Either way the verifier reports "unscheduled" and every game gets the slow-block intervals until the entry is written. So this change is behaviour-neutral on every chain as of today, and the operational requirement is identical to what it was before: the speedup activation has to be registered on ProtocolVersions before the fork, or the verifier stays on the slow cadence silently.

How to test?

just build-go-ffi
forge test --match-contract AggregateVerifier

32 passed, 0 failed on this branch.

The two cases that pin the index behaviour directly:

forge test --match-test test_intervalsForStartingBlock_speedupUnscheduled_succeeds -vv
forge test --match-test test_initialize_unscheduledSpeedupUsesSlowTimestamp_succeeds -vv

_importSpeedupSchedule builds a FAST_BLOCK_UPGRADE_INDEX + 2-long schedule and writes the activation at the constant, so the scheduled-speedup cases (test_intervalsForStartingBlock_selectsOnFirstFastBlock_succeeds, test_initialize_scheduleChangesAtL2ActivationBoundary_succeeds, test_initialize_straddlingGame_usesSlowInterval_succeeds) now exercise a 15-entry registry with Denim at 13 rather than a 14-entry one with Cobalt at 12.

Lock check — should be a no-op after the commit:

FOUNDRY_PROFILE=ci forge build --force --skip "/**/test/**" --skip "/**/scripts/**"
go run scripts/autogen/generate-semver-lock/main.go
git diff --exit-code snapshots/semver-lock.json

Note

test/L1/ProtocolVersions.t.sol still names Cobalt at index 12 (schedule[12] = 0; // Cobalt is unscheduled on Base mainnet.). That is a factual statement about contract registration order, not a targeting choice, and is unrelated to this change — left alone.

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1