feat(server): run modal sandboxes on the vm runtime

[kitlangton]

What

Modal sandboxes now always run on Modal's Full-VM runtime (beta, enabled for our account) instead of the default gVisor container, and the kill mechanism is fixed for it. Per the direction from today's call: one runtime, no knob — we're building for ourselves.

Why VM: a real kernel (6.12.8+ vs gVisor's userspace 4.19 shim) with real device nodes, so workspaces can run Docker and other kernel-dependent workloads — the "employee with a real computer" posture. Only filesystem snapshots are supported on it (no memory snapshots), which matches the chosen persistence design exactly.

How

• createModalSandbox passes experimentalOptions: { vm_runtime: true } unconditionally (caller-supplied experimental options are preserved and merged)
• Kill fix: on the VM runtime, process-group signals are accepted but not delivered — kill(-pgid, SIG) returns 0 and nothing dies, while direct-pid signals work (verified same PID namespace, clean signal masks, even SIGKILL no-ops as a group signal). The KILL script now enumerates the target group from /proc/*/stat (parsing past the last ) so comm names can't confuse fields) and signals each member directly, in two passes to catch children forked mid-scan
• Driver doc comments updated with measured VM exec floor (~285-535ms vs ~90-165ms on gVisor; latency still dominated by per-exec overhead, so the no-overrides design is unchanged)

Scope

packages/server only. No environment contract changes, no workspace domain model (that remains PR 5b).

Testing

• Live conformance leg (OPENCODE_TEST_MODAL=1) against a real VM-runtime sandbox: 10/10 including the kill regression test, three consecutive runs
• Without the gate: suite skips cleanly (10 skip)
• Typecheck: server, core, cli