@@ -192,7 +192,7 @@ Separate from the per-PR app suite, the **upgrade lane** tests the most common u
 
 - **Two Chainsaw phases bracketing the upgrade.** Chainsaw cannot pause mid-test for an external `helm upgrade`, so the flow is `chainsaw test seed` → external `helm upgrade` → `chainsaw test verify`, all under `hack/e2e-chainsaw-upgrade/` (its own `.chainsaw.yaml`). Orchestration (install-previous, the upgrade itself) stays BATS, matching the install/bootstrap split; assertions are Chainsaw.
 - **`cleanup.skipDelete: true`** in `hack/e2e-chainsaw-upgrade/.chainsaw.yaml` is what lets seeded CRs cross the phase boundary — the seed phase applies them, the verify phase (assert-only, no `apply`) re-observes them. The sandbox is torn down wholesale at end-of-job, so leaving resources is safe.
-- **DRY over the app suite.** Seed suites `apply` the *existing* app manifests by relative path (`../../../e2e-chainsaw/<app>/<app>.yaml`) rather than re-authoring CRs; the all-HRs-Ready gate is the shared `hack/e2e-wait-hr-ready.sh` (also used by `hack/e2e-install-cozystack.bats`); the baseline version is resolved by `hack/upgrade-prev-version.sh` (unit-tested by `hack/upgrade-prev-version_test.bats`). The CI sandbox lifecycle is shared with the app-suite `e2e` job through the composite actions under `.github/actions/e2e-{prepare,collect,teardown}/`.
+- **DRY over the app suite.** Seed suites `apply` the *existing* app manifests by relative path (`../../../e2e-chainsaw/<app>/<app>.yaml`) rather than re-authoring CRs; the all-HRs-Ready gate is the shared `hack/e2e-wait-hr-ready.sh` (also used by `hack/e2e-install-cozystack.bats`); the baseline version is resolved by `hack/upgrade-prev-version.sh` (unit-tested by `hack/upgrade-prev-version_test.bats`). The CI sandbox lifecycle is shared with the app-suite `e2e` job through the composite actions under `.github/actions/e2e-{download-assets,prepare,collect,teardown}/` — which is also why `hack/sandbox-runner-headroom.bats` follows a local `uses:` into the action it names, since the make target that marks a job as a sandbox lane now sits inside one.
 - **Cross-boundary state** other than CRs (the pre-upgrade CrashLoop/unbound-PV baseline and recorded PV bindings) is written to `/workspace/_out/upgrade-baseline/*.txt` by seed suites and diffed by the verify suites. The all-HRs-Ready gate + migration-stamp advance (the `cozystack-version` ConfigMap reaching `migrations.targetVersion`) are the authoritative health signals; the CrashLoop name-diff is a warning-only heuristic (pod names churn across an upgrade).
 - **Trigger — a `upgrade-e2e` job in `pull-requests.yaml`, parallel to `e2e`.** It is a sibling with the same `needs` (no dependency between them), so it adds no critical-path wall-clock. It runs on the release-promotion PR (`release` label) or any PR a maintainer opts in with the **`upgrade-e2e`** label. **Advisory / non-blocking** — its own check, gates nothing.
 - **The heaviest workload (a tenant Kubernetes cluster spanning the upgrade — the #2931 worker-rollover path) is env-gated OFF** behind `UPGRADE_E2E_TENANT_K8S`, via an early `exit 0` in a single `script` step (Chainsaw v0.2.15 has no test-level `skip`). It is the flakiest surface (nested KVM + DRBD + the #3231 tenant-worker image import) and needs dev-stand validation before being enabled in CI; the DB/Redis canaries + platform-health checks are the always-on core.