fix(L1): pin AggregateVerifier to a max supported upgrade id

[PelleKrab]

Problem

The prover image only knows the upgrades compiled into its binary, but
AggregateVerifier snapshotted the live tail scheduleId(). Registering a new
upgrade onchain (even unscheduled) moved the tail, so the contract and prover
ScheduleIDs diverged unless both were updated in lockstep.

Solution

AggregateVerifier now takes a MAX_UPGRADE_ID (via a ScheduleConfig struct)
and snapshots scheduleId(MAX_UPGRADE_ID), pinning games to the schedule
prefix the prover image supports:

• Registrations beyond the pin no longer affect deployed verifiers, so the
  registry can grow independently of deployed proof contracts.
• Schedule changes within the pinned prefix still move the commitment, so
  upgrades the prover must honor still invalidate stale proofs.
• The constructor queries the pinned index, so a deploy reverts if the
  registry has not registered up to it.

Deploy scripts seed the registry with unscheduled (registerUpgrade(0, 0))
entries through multiproofMaxUpgradeId so the constructor check passes;
governance schedules activations later. The config value is intentionally
mandatory (no default) since it must match the prover image's
BaseUpgrade::CONTRACT_VARIANTS.

Operational invariant

Nothing onchain ties L2 activation of upgrades beyond a game type's pin to
retiring that game type. Governance must switch the respected game type to an
implementation pinned at or above a new upgrade id before its activation
timestamp passes.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/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 1 Sum 2

[jackchuma]

Is this added to avoid a stack-too-deep error in the constructor?