Assign redemption budget lazily in redeem loop

[cyc60]

Description

Replaces the fixed-prefix budget pre-assignment in process-redeemer with lazy assignment inside the redeem loop, so skipped positions free their budget for later file entries.

Previously assign_shares_to_redeem pre-selected a prefix of file entries summing to queuedShares, and redeem_positions worked through that fixed prefix. Every skip inside the loop — meta vault, unharvested vault, LTV > 1, dead position, zero withdrawable, failed simulation or submission — simply continued, dropping its budget on the floor: entries after the prefix were never tried, and every subsequent cycle recomputed the exact same prefix, so the shortfall persisted with no escalation.

This is aggravated by the positions file being sorted LTV-descending: the most skip-prone positions (closest to liquidation, most likely to be repaid/liquidated) sit exactly at the head of the prefix by construction.

Example. Queue = 300 osETH; file entries: A (200 osETH, LTV > 1 → skipped), B (100 osETH, unharvested vault → skipped), C (150 osETH, healthy), D (200 osETH, healthy).

• Before: the prefix {A: 200, B: 100} consumes the whole 300 budget. Both are skipped; C and D are never even considered. Redeemed: 0, this cycle and every following cycle.
• After: the loop walks the file with remaining_shares = 300; A and B are skipped without consuming budget, C redeems 150, D redeems the remaining 150. Redeemed: 300.

Implementation: redeem_positions takes total_redemption_shares and decrements remaining_shares only after a successful submission; each entry contributes min(unprocessed_shares, live_shares, remaining_shares). The vault withdrawable-assets lookup is factored into _get_vault_withdrawable (cached per vault, unchanged behavior). assign_shares_to_redeem is no longer used by the redeemer daemon (it still drives the aggregation path).

Second PR of the redeem-loop stack — based on #820's branch (merge that first), followed by #822.