[FEATURE] Kind CI: install, upgrade and roll back from release bases with kubectl only #3679

Proves the release layout works without ate-setup. CI installs a release on kind using only the documented fresh-install commands, then upgrades from the previous release stage by stage in the version skew policy's order, and rolls back.

Tracks "Define install ordering and upgrade stages" (CI) in the Publish the install as kustomize bases workstream of the Extensible Install Roadmap.

Current state (0b635b80): the upgrade e2e test (#2712, merged 2026-11-04) drives upgrades through ate-setup.

Required changes

• Fresh install:
  1. apply crds/ and wait for Established;
  2. apply bootstrap/ and wait for the Job to complete;
  3. apply system/ and wait for every rollout.
• Settle early whether a single system/ apply converges when certificate-dependent workloads start before the certificate controller. If it does not, change system/ to apply stages/1-podcert first, and update [FEATURE] Release Layouts #3176.
• Upgrade, with actors running: bootstrap Job, then 1-podcert, 2-atelet, the WorkerPool image, 4-apiserver, crds/ + 5-controller, 6-atenet, 7-sandboxconfig, 8-rest.
• Rollback applies the previous release's stages in reverse and leaves 8-rest.

Dependencies: #3678.

Enforcement: the CI job is the enforcement for #3176. It asserts the previous release's SandboxConfig survives an upgrade and rollback, and that key Secrets are unchanged.

Parent Issue: #3169