[checkpoint] Make CritPt global batching checkpoint-safe

Parent

Child of #3223 and #3024.

Shared state

resources_servers/critpt/app.py owns process-global pending submissions, execution membership, futures/waiters, submission/batch counters, API-key cursor, and optional disk cache.

Proposed capability

Persist logical pending submissions/IDs, memberships, monotonic counters, key cursor, and committed cache identity. Rebuild runtime futures and locks, remove retired attempts, and avoid resubmitting committed batches.

Do not serialize futures, locks, credentials, waiters, or raw external handles. Capability reporting must distinguish coordinated-global, drain-only, and restart-only semantics from ordinary per-session export/restore.

Acceptance criteria

• Restore a partially filled batch and a persisted-before-fire batch without duplicate submission or cross-attempt contamination.
• Prepare accounts for every accepted shared operation and fails closed at its deadline.
• Process replacement leaves no stale waiter, batch member, metric interval, or actor reference.
• Duplicate prepare/restore/resume is idempotent or rejected deterministically.
• Cold restart and failure cleanup are covered.

Start with resources_servers/critpt/app.py and the parent issues #3223 and #3024 to map the process-global state and checkpoint boundaries. Use the acceptance criteria as the completion checklist, especially restore of partial and persisted-before-fire batches, replacement cleanup, idempotent resume, cold restart, and failure cleanup. Do not serialize runtime-only objects such as futures, locks, credentials, waiters, or external handles.