Implement the v2 commitment and challenge lifecycle

@snawaz is already working on this.

Since Sep 17, 2026.

### Goal

Implement the on-chain MagicBlock Protocol v2 commitment, challenge, resolution, and finalization flow under #132. Use permissioned admission, bonded participants, round-robin verifier selection, operator state uploaded and finalized before posting, challenger commit/reveal, and a configured multisig resolver.

### Why

Pending account-state commitments need verifier approval and a challenge-resolution path before they can be applied to the base layer.

### Scope

Finalization must enforce the applicable approval or dispute outcome and use state bound to the correct account, commit, and authority. Preserve v1 interfaces. Each instruction's dispatch, arguments, account definitions, processor, and builder must agree, with coverage of its successful path and relevant authorization, account-binding, and state-transition failures.

Stake withdrawal, challenge-window extensions, reveal timeout, and terminal cleanup remain in v2 scope even when lower priority than the core flow. A separate payout claim is required only if payouts are delayed. Native child issues own the detailed requirements and track progress.

The broader proposal includes paths not used by this v2 design: randomness-based selection and a separate operator response after a challenge. Round-robin selection and a pre-posting operator buffer replace those paths. Validator-side divergence detection and replay, future permissionless admission, and objective dispute resolution are outside this on-chain scope.

The [v2 implementation notes](https://github.com/magicblock-labs/delegation-program/blob/36e1efae94660460fdc6d823afb1fbc4c504e8a6/mimd-0024-impl.md) describe the design used by these issues; the older MIMD-0025 instruction list is historical. See [MIMD-0024](https://github.com/magicblock-labs/magicblock-validator/discussions/1207) for the broader proposal. Open policy decisions in the notes remain unresolved, not implicit implementation requirements.

Some closed children describe dropped work rather than implemented instructions. In particular, #222 is closed as completed while the referenced design still lists reveal-timeout handling as deferred; its implementation status needs reconciliation.