Proposal: Mitos device backend + collaboration on full-state fork semantics

We build [Mitos](https://github.com/mitos-run/mitos), an OSS snapshot-fork sandbox runtime: Firecracker microVMs forked via CoW snapshots, so a fork inherits the full running VM (memory, processes, open sockets), not just the filesystem, in ~80 ms warm. Reading your paper, we think there's a useful collaboration here, in increasing order of ambition: **1.** A device backend, our effort. We'd like to contribute (in-tree or as a third-party adapter, your call) a backend where Shepherd fork points map to full-VM fork. Happy to align with wherever the device interface is heading pre-1.0. **2.** An interface question worth settling before 1.0. The current fork contract appears filesystem-scoped. Should the device layer be able to express full-state fork, and where does inherited memory state sit in your reversibility tiers? We maintain a fork-correctness hazard catalogue (RNG, clocks, secret inheritance) that seems complementary to your taxonomy; we've cited your paper there. **3.** An experiment your current backends can't run. All backends in Appendix C.7 fork fs state only, so your results don't measure what warm memory/process state adds to CRO or tree-RL (e.g. branches that keep a running server or warm interpreter). We'd be glad to support a re-run on a full-state substrate, including bare-metal KVM hardware for reproducible benchmarks. Item 1 stands on its own if 2 and 3 aren't interesting. Would an issue thread here work, or is there a better channel?