[checkpoint] Restore litmus_agent code sandboxes

Parent

Child of #3222 and #3024. Depends on #3275.

Runtime state

resources_servers/litmus_agent/app.py owns a live sandbox, successful code-cell history, per-session lock, and verifier-visible filesystem.

Adapter requirements

Persist the logical execution-to-runtime mapping, provider/version and physical generation, sandbox snapshot/reference, image/spec and mount fingerprints, agent or verifier cursor, and result-manifest identity. Rebind a replacement runtime atomically and fence the old handle. Never claim that a filesystem-only copy restores unsupported live process state.

Acceptance criteria

• Provider snapshot is preferred; replay fallback rejects non-replay-safe filesystem, subprocess, environment, network, or nondeterministic effects.
• Mutate runtime state, commit, replace both application and runtime process where supported, restore, and compare the next operation/result.
• Stale handles and delayed old-runtime results are rejected.
• Partial restore activates no execution mapping.
• Duplicate retirement and failed-provider cleanup release the restored runtime exactly once.

Start by reading resources_servers/litmus_agent/app.py to understand the live sandbox, session lock, code-cell history, and verifier-visible filesystem. Trace the existing runtime lifecycle before designing restoration. Done means supported snapshots restore atomically, replay rejects unsafe effects, stale or delayed results are fenced, partial restores activate nothing, and cleanup releases the runtime exactly once.