bug: distinguish intentional signal stops from runtime restarts

Theo dõi cách các driver Docker và Podman xử lý các mã thoát 137/143, sau đó theo dõi cách ý định dừng của gateway và các snapshot watcher bị trì hoãn cập nhật trạng thái sandbox. Xem xét hành vi khôi phục hiện có liên quan đến các issue #2855 và #2179, đồng thời chạy hoặc mở rộng phạm vi kiểm thử hồi quy cho cả hai driver. Hoàn thành có nghĩa là các lần dừng có chủ đích vẫn ở trạng thái kết thúc và có thể phân biệt được, trong khi các lần khởi động lại runtime thực sự vẫn có thể khôi phục, còn OOM và các lần thoát thông thường không thay đổi.

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.