bug: distinguish intentional signal stops from runtime restarts

跟踪 Docker 和 Podman 驱动对退出代码 137/143 的处理，然后继续跟进 gateway 停止意图和延迟的 watcher 快照如何更新 sandbox 状态。检查与 issues #2855 和 #2179 相关的现有恢复行为，并为两个驱动运行或扩展回归测试覆盖。完成的标准是：有意停止仍保持为终态且可区分，而真正的运行时重启仍可恢复，同时 OOM 和普通退出保持不变。

User Story

As an OpenShell operator, I want sandbox status to distinguish an intentional shutdown from a runtime interruption, so that stopped sandboxes are not presented as having restarted unexpectedly and real runtime restarts remain recoverable.

Problem Statement

The Docker and Podman drivers currently classify exits 137 (SIGKILL) and 143 (SIGTERM) as ContainerRuntimeRestart. Those codes establish only that a process was terminated by a signal; they do not identify the sender or intent. An explicit gateway stop that forwards SIGTERM therefore produces the same condition as a Podman/Docker machine or daemon restart.

The durable Stopping phase now prevents that ambiguity from promoting an in-flight explicit stop to Error, but a delayed watcher snapshot can still arrive after Stopped is persisted and replace the user-visible status reason with ContainerRuntimeRestart.

Impact / Why This Matters

Operators can see a sandbox in Stopped phase with a contradictory runtime-restart condition after a normal stop. More broadly, treating all 137/143 exits as runtime restarts conflates graceful stop, forced timeout kill, external intervention, and genuine runtime interruption. The current workaround is to infer intent from lifecycle phase, which protects the immediate flow but does not make the driver status semantically precise.

Acceptance Criteria

• An explicit gateway stop remains Stopped when a late Docker or Podman signal-exit snapshot arrives, and its terminal status continues to report the intentional stop.
• A signal termination without explicit stop intent remains distinguishable from a confirmed runtime interruption.
• Gateway restart recovery continues to recover sandboxes interrupted by a real Docker or Podman runtime/machine restart.
• OOM termination and ordinary application exits keep their existing distinct behavior.
• Regression coverage covers Docker and Podman for explicit SIGTERM stop, forced SIGKILL timeout, delayed watcher delivery, OOM, and runtime/machine restart.

Reproduction Steps

1. Start a Docker- or Podman-backed sandbox.
2. Stop it through the gateway so the supervisor forwards SIGTERM to its workload.
3. Observe the driver report exit 143 as ContainerRuntimeRestart.
4. Deliver that watcher snapshot after the gateway has persisted Stopped.
5. Observe the sandbox phase remain Stopped while its condition reason no longer reflects the intentional stop.

Environment

• OpenShell: current main development build
• Compute drivers: Docker and rootless Podman
• Related issue: #2855
• Historical recovery behavior: #2179

Agent Investigation

ContainerRuntimeRestart is currently a heuristic for exit 137/143 in both Docker and Podman. The exit status has no provenance, so operation intent and independently observed runtime state must be considered separately.