fix(kubernetes): stop supervisor before workload (#3424)

* fix(kubernetes): stop supervisor before workload

Make Kubernetes sandbox stop crash-resumable and give supervisor Pod deletion its configured grace period plus API observation headroom.\n\nCloses #3421

Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>

* fix(kubernetes): harden resumed sandbox stops

Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>

* test(kubernetes): simplify resumed stop regression

Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>

* fix(kubernetes): generalize runtime control release

Signed-off-by: Drew Newberry <anewberry@nvidia.com>

* refactor(kubernetes): clarify stop phase names

Signed-off-by: Drew Newberry <anewberry@nvidia.com>

---------

Signed-off-by: Piotr Mlocek <pmlocek@nvidia.com>
Signed-off-by: Drew Newberry <anewberry@nvidia.com>
Co-authored-by: Drew Newberry <anewberry@nvidia.com>

Author: pimlock

architecture/compute-runtimes.md

@@ -186,6 +186,15 @@ A driver stop operation does not complete while its backend still reports an
 in-progress stop. This prevents an immediate start from racing the previous
 run's delayed exit event and regressing the new run to `Error`.
 
+The Kubernetes driver records stop as a durable two-phase transition. The
+`releasing` phase releases the sandbox's runtime-control relationship while the
+workload boundary remains reachable. The `suspending` phase then suspends the
+Agent Sandbox workload and cleans generation bootstrap material. The current
+dedicated-supervisor implementation releases control by deleting the supervisor
+Pod. Periodic reconciliation resumes either phase after a gateway restart. Pod
+deletion waits include the configured termination grace period plus Kubernetes
+API observation headroom.
+
 Persisted `Stopping` and `Starting` rows are retried at startup. Stable
 `Stopped` rows remain stopped. Docker and Podman retain the stopped container
 and attached storage, Kubernetes retains the Sandbox CR and PVC while scaling