ci(validate-k3s-rabbit): exercise flux-operator's real-path deployment

[dark-vex]

Summary

• flux-operator landed on k3s-rabbit via separate production PRs (feat(k3s-rabbit): Add flux-operator to k3s-rabbit #1799, fix(k3s-rabbit,flux): Add missing Flux Operator helm chart #1804, fix(k3s-rabbit): Fix apps file path for flux operator #1805) while the e2e coverage PR (ci(validate-k3s-rabbit): add e2e cluster validation workflow #1796) was still rebasing on top of them. Because of that timing, flux-operator was present in ci(validate-k3s-rabbit): add e2e cluster validation workflow #1796's base but never in that PR's own diff — every real run of ci(validate-k3s-rabbit): add e2e cluster validation workflow #1796 printed Apps to deploy: fluxcd only. So the workflow's tier-3 real-deploy path has never actually been exercised live for flux-operator on k3s-rabbit, unlike oc-ampere, where an identical gap was closed via a comment-only touch (PR ci(validate-oc-ampere): add e2e cluster validation workflow #1797, commit 66d5dfd4).
• This PR makes a comment-only edit to flux-operator's HelmRelease so it lands in this PR's own DEPLOY_APPS (derived from git diff against main), forcing this run to finally exercise the tier-3 real-deploy path for it.
• Also corrects several comments/docs across the workflow and cluster CLAUDE.md files that assumed k3s-rabbit's per-app e2e loop deploys zero apps "by design" — stale since flux-operator was added as a real, non-excluded app.

Safety reasoning

flux-operator is not in validate-k3s-rabbit.yml's EXCLUDED_APPS, so it resolves via tier 3 (real deploy.yaml fallback) — the same mechanism already relied on for oc-ampere. Re-verified independently this session via a fresh live helm template render of chart v0.57.0 (not just reused from the earlier oc-ampere check): the chart produces zero Helm hooks and no FluxInstance object; its Deployment just starts the operator controller, which idles until a FluxInstance CR exists. k3s-rabbit's root kustomization.yaml still has no flux-instance.yaml entry, so that CR is never created during an e2e run — same as oc-ampere. A parallel Codex review confirmed no k3s-rabbit-specific hazard, and confirmed the || true guard on flux get helmreleases -A is generic and won't regress now that a real HelmRelease can exist.

Test plan

• Confirmed locally: the only clusters/k3s-rabbit/apps/** path touched is flux-operator/manifests/release.yml, so DEPLOY_APPS will resolve to flux-operator only.
• Confirmed flux-operator/deploy.yaml's only dependsOn is charts (already Ready by that point in the workflow), matching tier 3's documented assumption.
• Confirmed charts/flux-operator.yml (the HelmRepository) exists on k3s-rabbit.
• Watch this PR's own validate-k3s-rabbit.yml run — confirm flux-operator's Kustomization/HelmRelease reach Ready via the tier-3 real-deploy path, confirm the "Check resource deployment status" step still passes cleanly now that a real HelmRelease exists, and confirm the job's other steps (bootstrap, GitRepository, top-level system-upgrade-controller) stay green.

🤖 Generated with Claude Code