MixinReserve.claimableReserve() mid-round accounting mismatch when transcoder pool size and current-round active set diverge

Nobody has claimed this yet.

### Summary

[`MixinReserve.claimableReserve()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/pm/mixins/MixinReserve.sol#L36) reads two data structures that can fall out of sync within one round. Claimant eligibility is gated on [`bondingManager().isActiveTranscoder(_claimant)`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/pm/mixins/MixinReserve.sol#L41) (a current-round snapshot), while the reserve allocation is divided by [`bondingManager().getTranscoderPoolSize()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/pm/mixins/MixinReserve.sol#L45) (the live pending transcoder pool counter). When the pending pool shrinks or grows mid-round (e.g. via [`resignTranscoder()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1459) or [`tryToJoinActiveSet()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1414)), the eligible active set and the divisor diverge, causing the per-claimant reserve cap to deviate from the fair `R / N` allocation in either direction.

### Root cause

[`isActiveTranscoder()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/pm/mixins/MixinReserve.sol#L41) is gated on `activationRound <= currentRound < deactivationRound`, which is a round-level snapshot. [`getTranscoderPoolSize()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1137) returns the live size of the `transcoderPool` linked list, which is mutated immediately by bonds, unbonds, evictions, and resignations.

When an active transcoder fully unbonds in round `r`:

* [`resignTranscoder()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1459) removes them from `transcoderPool` immediately, so [`getTranscoderPoolSize()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1137) returns `N - 1`.
* It sets `deactivationRound = currentRound + 1`, so [`isActiveTranscoder()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/pm/mixins/MixinReserve.sol#L41) still returns `true` for the remainder of round `r`.

The set of eligible claimants has size `N`, but the divisor is `N - 1`. Every eligible share is inflated by `N / (N - 1)`. The symmetric case (new transcoder joining via [`tryToJoinActiveSet()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1414) when a slot is free) deflates the cap in the same way.

### Why it's not an issue

* **No theft.** The redeemed amount is bounded by the ticket's `faceValue` and can never exceed the face value the broadcaster explicitly signed. No funds are created beyond what the broadcaster committed.
* **Grief is temporary.** `claimFromReserve` is explicitly designed to pay `min(shortfall, claimableReserve)`, not the full face value. Partial reserve payment for a valid ticket is normal protocol behavior. After a revert, `usedTickets[hash]` remains false and the ticket can be retried in a later round (subject to `ticketValidityPeriod`).
* **Restrictive preconditions.** The attack requires (1) a valid pre-signed winning ticket where `faceValue - deposit > R / N`, (2) the attacker accepting the opportunity cost of fully unbonding (or coordinating with a separate pool-shrinker), and (3) no other transcoder bonding into the freed slot between the pool shrink and the redeem call. Splitting the pool-shrinker and the overclaimer into separate accounts reintroduces a race: the pool shrink and the redemption can no longer be bundled into one transaction, so any transcoder bonding into the free slot between the two steps restores the pool size and cancels the inflation.
* **Protocol spec acknowledges the behavior.** The Livepeer technical spec documents a scenario where an orchestrator sets their ticket's face value to `R / N`, but by the time they redeem, the active set has grown to `N + 1`, dropping the cap to `R / (N + 1)`. This is treated as a known limitation of the reserve mechanism. The invariant `claimableReserve == R / active_set_size at all times` is not guaranteed by the spec.

### Out of scope for bug bounty

Reports targeting the `claimableReserve` accounting mismatch in [`MixinReserve.sol`](https://github.com/livepeer/protocol/blob/delta/contracts/pm/mixins/MixinReserve.sol), and the associated griefing/payment-disruption paths through [`MixinTicketBrokerCore.redeemWinningTicket()`](https://github.com/livepeer/protocol/blob/delta/contracts/pm/mixins/MixinTicketBrokerCore.sol), [`BondingManager.resignTranscoder()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1459), or [`BondingManager.tryToJoinActiveSet()`](https://github.com/livepeer/protocol/blob/6e6b452634542ff92b93643196a97ff356bac230/contracts/bonding/BondingManager.sol#L1414), are closed as known issues and not eligible for rewards under the [Livepeer Immunefi bug bounty program](https://immunefi.com/bug-bounty/livepeer/information/).

### References

* Source: [`contracts/pm/mixins/MixinReserve.sol`](https://github.com/livepeer/protocol/blob/delta/contracts/pm/mixins/MixinReserve.sol)
* Related: [`contracts/pm/mixins/MixinTicketBrokerCore.sol`](https://github.com/livepeer/protocol/blob/delta/contracts/pm/mixins/MixinTicketBrokerCore.sol), [`contracts/bonding/BondingManager.sol`](https://github.com/livepeer/protocol/blob/delta/contracts/bonding/BondingManager.sol)
* Deployed TicketBroker (Arbitrum): [`0xa8bB618B1520E284046F3dFc448851A1Ff26e41B`](https://arbiscan.io/address/0xa8bb618b1520e284046f3dfc448851a1ff26e41b)

Start with contracts/pm/mixins/MixinReserve.sol, then trace MixinTicketBrokerCore.redeemWinningTicket() and BondingManager.resignTranscoder() or tryToJoinActiveSet(). The issue describes a documented, out-of-scope accounting mismatch and does not specify a code change or acceptance test, so no concrete completion condition is provided.

Written by the indexing model from the issue text.