Argo Rollouts: enter drills into pods, t promotes / aborts / retries / pauses / restarts

[ShmuelOps]

Problem

A Rollout (rollouts.argoproj.io) row behaves like an unknown CRD in sofka today: ⏎ opens its YAML, t is refused ("suspend/resume only applies to…"), and the header hints enter yaml. Driving a canary — promote it, abort it, restart it — means leaving for the Argo Rollouts dashboard or the kubectl plugin, even though the t action-menu pattern already exists for Argo CD, Flux, and CronJobs.

Proposal

Two pieces, both guarded by the argoproj.io API group like the CAPI machinedeployments arm, so a kind that happens to share the plural keeps its configured drill or YAML.

1. ⏎ on a Rollout drills into its pods by spec.selector.matchLabels, scoped as rollout/<name> — exactly what a Deployment does. spec.selector is required on a Rollout in both the template and workloadRef forms, so the selector is always there.

2. t on a Rollout opens an "Argo Rollouts" menu: Promote, Promote full, Pause, Retry, Abort, Restart (the verbs the plugin and the dashboard have). Bulk on marked rows like the other menus. Each sends exactly the merge patches kubectl argo rollouts sends, taken from the plugin's promote.go / abort.go / retry.go / restart.go / pause.go:

Verb	Patch
Promote	unpause spec.paused; clear status.pauseConditions; after an inconclusive analysis under controller pause, also clear controllerPause and step on; for a canary mid-analysis with nothing paused, step to the next currentStepIndex
Promote full	unpause; status.promoteFull=true unless currentPodHash == stableRS
Pause	spec.paused=true
Retry	status.abort=false
Abort	status.abort=true
Restart	spec.restartAt=<now>

status patches go through the status subresource; on a 404 (subresource not served) the plugin's unified patch is sent to the object instead, then the spec half. Promote GETs the live Rollout first because which fields to clear depends on where it is paused. No plugin binary.

3. Header hints on Rollouts read enter pods / t promote/abort/….

Shape

• rollout_kind() next to argocd_kind(); ROLLOUT_MENU_ITEMS; a RolloutAction enum and one do_rollout_action driver in app/actions.rs; pure patch builders (rollout_promote_patches and friends) in app/helpers.rs, unit-tested case by case against the plugin's decision tree.
• Tests through handle_key for the menu (incl. bulk), the drill (incl. esc back), and the header hints; Cluster::fake() registers argoproj.io/rollouts.
• Docs: docs/features.md bullet, docs/keys.md enter + t rows, ? help string for t.

A preview exists in the closed #572; I'd rebase and reopen it if this is agreed.

Open questions

1. In scope for sofka at all? It's a different CRD from Argo CD (same group), and the menu is writes — but on t, where sync/suspend already live.
2. Menu set: the six above, or just promote / abort / retry (the ones that unblock a stuck rollout) with pause / restart / promote-full left out?
3. Should promote read argocd-cm-style overrides or anything cluster-side, or is mirroring the plugin's patches exactly the right contract?