Support large-account commits in MagicBlock Protocol v2

@snawaz is already working on this.

Since Sep 14, 2026.

### Goal

Commit and finalize account states larger than 10 KiB (10,240 bytes) through MagicBlock Protocol v2, including changes that grow the destination account.

### Why

The existing buffered commit path creates a full-sized commit-state PDA in one CPI, which can fail with `Failed to reallocate account data` for large states. The [reported devnet transaction](https://explorer.solana.com/tx/4YPwjdMP8LvSXHuAg7nLiooeCPaTobaKno6JanNXNNB6uDsNvHp2cyu9mwLm6xdwrUa4TZpBMpCPYLdG7DfogMx7?cluster=devnet#ix-3) demonstrates the original failure. MBV now rejects oversized accounts earlier; that makes the limitation clearer but does not provide support.

V2 already has [incremental state-buffer uploads](https://github.com/magicblock-labs/delegation-program/blob/36e1efae94660460fdc6d823afb1fbc4c504e8a6/src/v2/processor/fraud_proofs/write_state_buffer.rs), while [finalization still resizes the destination in one call](https://github.com/magicblock-labs/delegation-program/blob/36e1efae94660460fdc6d823afb1fbc4c504e8a6/src/v2/processor/fraud_proofs/finalize_commitment.rs#L124). Buffer capacity alone does not establish end-to-end support.

### Scope

- Complete the v2 upload, commit, and finalize flow within runtime allocation limits. Distinguish a large existing account from an update that increases its size by more than 10,240 bytes.
- Reuse the v2 state-buffer work tracked by #216 and finalization work in #224. Validator-side scheduling restrictions and delivery preparation are owned by [magicblock-validator#878](https://github.com/magicblock-labs/magicblock-validator/issues/878).
- Verify large same-size updates, shrinking updates, and growth across the allocation boundary, with the expected bytes, lamports, and rent after finalization.
- Keep the committed state bound to its account, commit id, and authority throughout any preparation steps.
- #202 contains an unmerged legacy preallocation approach; it is implementation context, not a requirement to adopt that API. Large delegation belongs to #80, and the undelegation lifecycle belongs to #203.

This is v2 work under #132. Backporting support to v1 is outside this issue.