Implement MagicBlock Protocol v2

@snawaz is already working on this.

Since Jan 5, 2026.

### Goal

Deliver MagicBlock Protocol v2 (formerly Delegation Program): delegation, commitments, verifier approval, fraud proofs, and the supporting account and instruction lifecycle. The new name reflects the program’s scope beyond delegation.

### Scope

- #203: streamline delegation and undelegation account lifecycle.
- #234: implement fraud proofs and supporting instructions.
- #239: remove the unused v2 commit-frequency setting.
- magicblock-labs/magicblock-validator#1700: rename the program and interface packages and update consumers.
- Cover Delegate, Commit, Finalize, Undelegate, and CallHandler, including their required supporting instructions.

Lower-priority tasks remain in v2; priority determines sequencing, not scope. Conditional work stays conditional—for example, a separate payout claim is needed only when payouts are delayed. Keep v1 interfaces unchanged unless separately scoped.

Keep the fraud-proof checklist in #234, including lower-priority tasks and historical dropped work. Dropped designs are not v2 requirements. The [implementation notes](https://github.com/magicblock-labs/delegation-program/blob/36e1efae94660460fdc6d823afb1fbc4c504e8a6/mimd-0024-impl.md) describe the v2 design and its differences from the broader proposal.

### Performance constraints

**Validation and PDAs**

- Pass bumps instead of using `find_program_address`. Avoid `create_program_address` where possible; consider `derive_address`.
- Minimize key comparisons and fail early, with cheap checks first.
- Use PDA signing only when necessary. Cache derived PDAs in state when reused.

**Memory and accounts**

- Avoid heap allocations; favor zero-copy and avoid copying types larger than 8 bytes.
- Avoid `u128` / `U256` arithmetic on hot paths. Prefer fixed-size account layouts.
- Merge accounts where possible, minimize loaded account data, and keep cold data out of hot-path accounts.
- Avoid creating or reallocating accounts during commit/finalize.
- Reuse code to limit binary size; avoid abstractions that prevent hot-path inlining.

**Instructions**

- Keep each commit or finalize operation self-contained in one instruction, without helper instructions or in-program retry logic.
- Minimize instruction count per operation. Avoid CPI and reliance on ComputeBudget on commit/finalize hot paths.
- Separate buffer uploads, commitment posting, verifier approvals, challenge windows, and dispute resolution remain part of the lifecycle. They do not violate the per-operation constraint; large buffers may need multiple upload instructions.

**Logging and build configuration**

- No logs on success. Include detailed failure logs with the instruction discriminator.
- Feature-gate debug and validation logic.