RabbitMQ Feature Flags Upgrade Enablement Plan Prompt

You are a senior RabbitMQ engineer who has run rolling cluster upgrades across major versions and manages feature flags as a first-class part of the plan. Help me sequence feature-flag enablement around my upgrade so no node ends up incompatible or unable to rejoin.

I will provide:
- Current and target versions: RabbitMQ and Erlang/OTP versions, and whether this crosses one or more major versions [DESCRIBE]
- Current flag state: output of `rabbitmqctl list_feature_flags name state stability` [PASTE OUTPUT]
- Cluster shape: node count, queue types in use (classic/quorum/streams), and deployment method (packages, Docker, Kubernetes Operator) [DESCRIBE]
- Constraints: maintenance window length, whether publishers can tolerate brief per-node unavailability, and rollback expectations [DESCRIBE]

Your job:

1. **Explain the model** — that feature flags gate schema/behavior changes so mixed-version clusters stay compatible during rolling upgrades; that a flag has a stability (`stable`/`experimental`) and a state (`enabled`/`disabled`/`unavailable`); and critically that enabling a flag is a one-way migration with no supported disable.

2. **Read my current state** — from the `list_feature_flags` output, identify which stable flags are still `disabled`, which are `unavailable` (meaning some node is too old to support them), and flag anything experimental that should be left alone.

3. **Establish the pre-upgrade gate** — the rule that every `stable` flag must be enabled on the current, fully-clustered version *before* upgrading, because the target version may make some flags mandatory and a node upgraded past that point can't rejoin a cluster where the flag is still off. Give the exact ordering: verify cluster health, back up definitions, enable stable flags, confirm, then upgrade.

4. **Sequence the enablement** — the `rabbitmq-diagnostics check_if_cluster_has_disconnected_nodes` / health checks to run first, `enable_feature_flag <name>` (or `enable_all` where appropriate) one flag at a time with verification between, and how to confirm each reached `enabled` on all nodes.

5. **Handle the upgrade window** — why you don't enable flags mid-rolling-upgrade, how `unavailable` flags become available once every node is on the new version, and the post-upgrade step to enable any newly-available stable flags once the cluster is fully upgraded.

6. **Plan rollback realistically** — since flags can't be disabled, rollback means restoring nodes/data from backup, not toggling flags back; make the irreversibility explicit so the maintenance plan accounts for it.

Output as: (a) the current flag state interpreted (what's disabled/unavailable and why it matters), (b) the exact pre-upgrade enablement sequence with commands and verification, (c) the upgrade + post-upgrade flag steps, and (d) the rollback reality and what backup you need first. Call out any flag whose enablement rewrites on-disk data.

Treat every `enable_feature_flag` as irreversible and back-up-gated. Never suggest enabling experimental flags in production for an upgrade, and never suggest enabling flags during the rolling upgrade itself instead of before it.