test(conformance): verify deterministic shutdown and signal processing across drivers #5285

User Story

I maintain OpenShell's conformance tests and CI. I need deterministic coverage that sandbox shutdown processes termination signals correctly across drivers, so a runtime that waits for grace-period SIGKILL cannot pass just because its delete request returns quickly.

Description

Define and test the common shutdown behavior supported by the Kubernetes and Podman drivers. Exercise the supported sandbox lifecycle/signal contract and require observable evidence of successful signal processing and shutdown, without grace-period SIGKILL of the runtime components under test.

First establish the exact common contract and test seam. Use supported lifecycle operations; do not assume OpenShell exposes a direct signal API. Determine which stop/delete paths deliver termination signals and what the boundary, supervisor and workload are each required to do. A workload may intentionally be killed during containment; do not confuse that with the boundary or supervisor failing to process its own termination signal.

Use a controlled fixture with a readiness handshake and observable termination evidence. Specify how to retain that evidence across deletion. A fast CLI/API return alone is insufficient: it may precede actual termination or hide a supervisor still waiting for SIGKILL. Driver-specific observation may be needed to establish the same behavioral assertions. If the required evidence cannot be obtained at the current conformance boundary, document the gap and agree on a narrow test seam rather than silently weakening the assertion.

A deadline bounds liveness and prevents a hanging test. It is not a performance benchmark or a requirement to reproduce a particular deletion duration.

Context

Parent: #5281.

• Discussion: Drew requested a deterministic behavior test asserting that the signal was processed correctly, and cross-driver conformance because similar failures have occurred on Podman and Kubernetes.
• bug(sandbox): on Kubernetes, deleting a sandbox waits out the pods' termination grace period #5025 reports Kubernetes boundary and supervisor processes waiting out the termination grace period.
• fix(sandbox): bound runtime shutdown after SIGTERM #5279 fixes the boundary runtime shutdown and adds a boundary-level SIGTERM regression test. It reports Kubernetes deletion improving from roughly 32 s to 4–6 s, but notes that the supervisor can still wait for grace-period SIGKILL. That regression test and timing evidence do not replace cross-driver conformance.
• test(e2e): split credential_gating into independent parallel tests #5264 splits credential-gating tests. It addresses test structure/timeouts, not this shutdown contract.
• refactor(compute): standardize lifecycle coordination across drivers #4115 covers lifecycle coordination races; refactor(compute): define driver shutdown and restart lifecycle contract #2417 covers driver-process shutdown/restart ownership. Those are related but do not provide this sandbox signal-processing conformance coverage.

This issue tracks coverage and contract definition only. Keep it separate from credential-gating splitting, migration prep (#5275), and optional nightly performance monitoring.

Definition of Done

• Specify the supported common lifecycle/signal contract for Kubernetes and Podman, including which processes must terminate and how successful signal processing is observed.
• Agree on a deterministic fixture and test seam, with readiness synchronization and evidence retained after shutdown/deletion; no unsupported direct signal API is assumed.
• Add cross-driver conformance coverage requiring observable successful signal processing and actual shutdown, not only successful or fast lifecycle-call return.
• Establish that the runtime components under test do not rely on grace-period SIGKILL; account explicitly for intentional workload containment.
• Demonstrate that the test detects a controlled ignored/unprocessed-signal regression and passes the corrected behavior on Kubernetes and Podman.
• Use a documented bounded-liveness deadline and report useful termination evidence on failure, without introducing a performance benchmark.