Define committor shutdown behavior with durable recovery

@snawaz is already working on this.

Since Sep 9, 2026.

• #1368 by @taco-paco — open

## Goal

Define committor shutdown behavior when accepted work cannot finish draining, without losing recoverable progress or leaving callers waiting for results that will never arrive.

## Why

Current `dev` already [stops ingress and drains results](https://github.com/magicblock-labs/magicblock-validator/blob/073cd6e6a22b1a919119ec4241db08bb2abab932/magicblock-committor-service/src/service.rs#L120-L144). The remaining question is what happens when that drain cannot complete. Interrupting a submitted transaction does not establish whether it executed on base.

## Scope

Choose and document the drain/deadline policy, including what ends a drain and what callers observe at that boundary. Whether to keep waiting or stop after a deadline is a design decision, not a requirement to wait indefinitely or abort immediately.

Build on the contracts owned by the #1701 workstreams:

- #1702 supplies durable progress and transaction reconciliation after interruption. Define which accepted work remains recoverable at shutdown and reuse that mechanism to reconcile submitted transactions before retrying; do not introduce another recovery path.
- #1704 gives already-scheduled dependents failure results, but new admission-time rejections receive no result broadcast. Shutdown accounting must distinguish them rather than wait for notifications that cannot arrive.
- #1705 moves admission and result-subscription ownership into the committor processor. Align stopping ingress, tracking accepted work, and ending result observation with that ownership, and make completion, rejection, and interrupted waits clear to callers.