Route unstake to the rollup where the stake actually lives

[koenmtb1]

Users with stakes deposited before a canonical rollup upgrade couldn't initiate or finalize unstake, the dashboard sent the write to the deposit-time rollup, but the protocol had auto-migrated their stake to the new canonical (moveWithRollup = true). Concrete example: tx 0xcd6074ec….

Three coordinated layers fix this:

1. Dashboard probe, useAttesterViewBestEffort probes canonical + legacy (+ optional indexer hint) rollups in parallel and writes go to whichever holds the live record (effectiveRollup), not the indexer-supplied deposit rollup. Chain is always authoritative.

2. Indexer hint, moveWithRollup decoded from originating tx calldata via selector-keyed dispatch (atp-indexer/src/utils/move-with-rollup.ts). effectiveRollup bulk-updated on Registry:CanonicalRollupUpdated for rows that auto-migrate AND aren't mid-exit (the exit pins to where initiateWithdraw was called, verified via latest_initiate_ts > latest_finalize_ts SQL aggregation).

3. Version resolution, useRollupVersionFor(effectiveRollup) resolves the per-stake on-chain version. WithdrawalActions disables buttons while resolving so a cart entry can't be built against the canonical version when the stake lives on legacy.

Schema additions (moveWithRollup boolean, effectiveRollup hex notNull + index) on deposit / staked / stakedWithProvider / erc20StakedWithProvider. Schema versions bumped (testnet v03→v04, prod v21→v22) — full reindex on next deploy, blue-green handles the cutover.