feat: queue stake updates

[0xCardiE]

Summary

• replace immediate staking mutations with queued stake updates for deposits, top-ups, height changes, overlay changes, withdrawals, and exits
• simplify effective stake so an unfrozen node's effective stake is just its current balance, and a frozen node's effective stake is 0
• add forward-looking staking preview getters with explicit lookahead semantics instead of AtRound naming
• reconcile queued withdrawals after slashing so queued payouts cannot exceed the remaining stake
• make redistribution claim payout atomic with the postage withdrawal
• update deployment config and tests to cover the new staking lifecycle, withdrawal/exit behavior, payout retry behavior, winner selection stability, and Bee-facing preview semantics
• harden error paths: applyUpdates reverts on frozen withdrawals/exits, post-exit operations revert QueueClosed instead of NotStaked, constructor validates wait-parameter ordering
• expose UPDATE_QUEUE_MAX_LENGTH as a public constant
• remove dead code: unused Frozen error, duplicate StakeState struct (merged into Stake), redundant _toStakeView conversion
• fix _applyReadyUpdates so privileged callers (freezeDeposit, slashDeposit, migrateStake) can never be blocked by a frozen withdrawal — they skip frozen entries instead of reverting

Bee Node Changes

• Bee must no longer assume staking changes become effective immediately. createDeposit, addTokens, increaseHeight, changeOverlay, withdraw, and exit now enqueue updates that only become effective after the relevant wait period and after applyUpdates(owner) materializes them on-chain.
• Bee should read the staking contract wait parameters instead of hardcoding timings:
  • WAIT_BASE for deposit, top-up, and height increase
  • WAIT_OVERLAY_CHANGE for overlay changes
  • WAIT_WITHDRAWAL for withdraw and exit
• On deployed networks, WAIT_WITHDRAWAL is intended to represent roughly a 28-day delay in rounds. Local development configs may still use short values.
• After the relevant wait period has elapsed, Bee should call applyUpdates(owner) to materialize ready updates on-chain. This is especially important for withdrawals and exits, because the BZZ transfer is only executed during applyUpdates(owner).
• If a queued withdrawal or exit has reached its effective round but the node is still frozen, applyUpdates(owner) reverts with FrozenWithdrawal(). Bee should catch this revert and retry after the freeze expires. The frozen update stays in the queue and will execute on a subsequent applyUpdates call once the node is unfrozen.
• Bee should continue to use Redistribution.isParticipatingInUpcomingRound(owner, depth) as the source of truth for eligibility. Bee should not try to reconstruct that decision from plain StakeRegistry getters alone, because redistribution combines staking state with round/anchor logic.
• Bee should treat nodeEffectiveStake(owner), overlayOfAddress(owner), heightOfAddress(owner), and stakes(owner) as the currently effective staking state only. Queued future state is not implicitly exposed through those getters.
• If Bee needs forward-looking raw staking previews, the explicit preview getters are now:
  • nodeEffectiveStakeLookahead(owner, lookahead)
  • overlayOfAddressLookahead(owner, lookahead)
  • heightOfAddressLookahead(owner, lookahead)
• lookahead = 0 means "effective state for the current round context", and lookahead = 1 means "effective state one round ahead". This replaces the previous absolute-round preview naming.
• Bee should continue participating under the old effective balance and metadata while updates are still waiting in the queue. A newly requested overlay or height must not be used for commit or reveal until the delay has passed and applyUpdates(owner) has succeeded.
• Bee should treat nodeEffectiveStake(owner) as the live effective stake value. The previous committed/potential split is gone.
• Bee may queue staking updates while frozen, but frozen nodes still cannot participate, and queued withdrawals or exits will not execute until the freeze no longer blocks them.
• After exit() is queued, the owner's staking queue is closed. Any subsequent call to createDeposit, addTokens, changeOverlay, increaseHeight, withdraw, or exit reverts with QueueClosed(). No further staking updates can be enqueued for that owner until the exit is applied and the queue is cleared. Bee should treat a queued exit as a terminal pending action for that stake position.
• Bee can read UPDATE_QUEUE_MAX_LENGTH on-chain to check queue capacity before enqueuing. The queue reverts with UpdateQueueFull() when the limit is reached.
• Bee operators that are migrating existing integration logic should update any workflow that previously relied on immediate post-transaction staking state. The safe sequence is:
  1. submit staking change
  2. wait for the contract-defined round delay
  3. call applyUpdates(owner)
  4. continue with actions that depend on the new state

Deployment Notes

• The constructor now enforces WAIT_OVERLAY_CHANGE >= WAIT_BASE and WAIT_WITHDRAWAL >= WAIT_BASE. Deployment scripts that pass wait parameters violating this invariant will fail with InvalidWaitConfiguration().

Contract Cleanup

• Removed unused Frozen error declaration.
• Merged identical StakeState struct into Stake — the duplicate struct and _toStakeView conversion function were dead weight since the fields were identical.
• Moved the _queueClosed guard from _enqueueUpdate into all six public caller functions. This ensures QueueClosed is the first revert a user sees when the queue is terminating, before any gas is spent on _previewStake. The createDeposit function previously lacked this guard entirely.
• _applyReadyUpdates now takes a _revertOnFrozen parameter. Public applyUpdates passes true (reverts with FrozenWithdrawal). Privileged callers (freezeDeposit, slashDeposit, migrateStake) pass false (breaks out of the loop) so the redistributor can always freeze and slash, and migration always succeeds.

Redistribution Notes

• claim() now keeps payout and round finalization atomic. If the postage payout fails, the whole claim reverts and can be retried later once the underlying issue is resolved.
• This avoids a state where a round is marked as claimed but the winner was not paid.
• Upcoming-round eligibility now uses the staking lookahead preview API rather than target-round naming, so the staking/redistribution interface more clearly expresses forward preview semantics.

Reference

• SWIP draft: https://github.com/awmacpherson/SWIPs/blob/swip-40-41-combined/SWIPs/swip-40%2B41.md