Real snapshotting for fork+restore #205

Context

EpisodeService.checkpoint / restore / fork exist today but they
do kill+restart, not real snapshotting:

• checkpoint records the request log offset + copies the agent
  workspace
• restore / fork start a fresh runtime with the saved workspace
  contents

That works because the cyber pack's HTTP server is essentially
stateless modulo the log + flag arg. Restarting it produces an
equivalent world.

Future packs won't be that lucky:

• Trading sims have order-book state that takes work to get into
• Robotics sims have rigid-body state that you can't recreate
• Containers with running processes (databases, message queues)
  can't be cheaply rebuilt

For those, fork should mean actual state snapshot, not "kill and
re-init."

What this issue tracks

Add real snapshotting capability for runtime backings that need it.
Concretely:

• Implement RuntimeBacking.checkpoint(instance) to capture state
  in a way restore(checkpoint, ctx) can rebuild from.
• Pick a snapshotting tech per backing class:
  • Containers: CRIU, docker commit, overlayfs commit
  • Subprocess with stateful protocol: pickle the state machine
    over an admin socket
  • Filesystem state: copy or hardlink the data dir

The RuntimeBacking protocol already has the hooks
(checkpoint / restore). They're no-ops by default; this issue is
about real implementations.

Why it matters

Without real snapshotting, fork-based counterfactual training is
limited to stateless worlds. As packs ship that need stateful
runtimes (trading, robotics, hybrid sims), fork either has to
flatten back to "rebuild from manifest" (slow, may diverge from
parent) or this issue lands.

Where to start

• src/openrange/core/runtime_backing.py — the protocol with
  checkpoint / restore already declared.
• src/openrange/core/backings.py — HTTPBacking (today's
  in-process, kill+restart impl).
• src/openrange/core/episode.py — the EpisodeService.fork() flow
  that calls restore.
• Issue Add a Kind runtime backing (cyber pack) #189 (multi-process backing) — natural place to wire in
  multi-process snapshot support.

Suggested phasing

This is research-flavored. No near-term consumer; pick it up when a
pack ships that needs it.

If you want to drive: open a design doc PR with one specific
backing's snapshot strategy + perf budget. Don't try to design "all
snapshotting" at once.

Acceptance

• A RuntimeBacking implementation that does real snapshot/restore
  for some non-trivial backing (containers + processes inside them
  is the canonical hard case).
• A test showing fork() produces a sibling whose state diverges
  from the same starting point, not from "manifest re-init."

Notes

Filed for visibility. Don't expect this to land soon unless there's
a forcing function (a stateful pack that needs it).