DOC-2237: correct decommission + maintenance mode guidance (#1735)

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: Feediver1

modules/manage/pages/cluster-maintenance/decommission-brokers.adoc

@@ -20,6 +20,8 @@ There are two ways to decommission brokers in Redpanda:
 
 Both methods permanently remove the broker from the cluster. Decommissioned brokers cannot rejoin.
 
+NOTE: Entering xref:manage:node-management.adoc[maintenance mode] before decommissioning is optional. Decommissioning drains partition leadership gracefully on its own.
+
 == What happens when a broker is decommissioned?
 
 When a broker is decommissioned, the controller leader creates a reallocation plan for all partition replicas that are allocated to that broker. By default, this reallocation is done in batches of 50 to avoid overwhelming the remaining brokers with Raft recovery. See xref:reference:tunable-properties.adoc#partition_autobalancing_concurrent_moves[`partition_autobalancing_concurrent_moves`].

modules/manage/pages/kubernetes/k-decommission-brokers.adoc

@@ -25,6 +25,8 @@ There are two ways to decommission brokers in Redpanda:
 
 Both methods permanently remove the broker from the cluster. Decommissioned brokers cannot rejoin.
 
+NOTE: Entering xref:manage:node-management.adoc[maintenance mode] before decommissioning is optional. Decommissioning drains partition leadership gracefully on its own.
+
 == Prerequisites
 
 You must have the following:

modules/manage/pages/node-management.adoc

@@ -6,7 +6,7 @@
 
 Maintenance mode lets you take a Redpanda broker offline temporarily while minimizing disruption to client operations. When a broker is in maintenance mode, you can safely perform operations that require the Redpanda process to be temporarily stopped; for example, system maintenance or a xref:manage:cluster-maintenance/rolling-upgrade.adoc[rolling upgrade].
 
-CAUTION: A broker cannot be decommissioned while it's in maintenance mode. Take the broker out of maintenance mode first by running `rpk cluster maintenance disable <node-id>`.
+NOTE: Putting a broker into maintenance mode before decommissioning is optional. Decommissioning gracefully drains partition leadership on its own, so you can decommission a broker directly without first entering maintenance mode.
 
 When a broker is placed in maintenance mode, if the replication factor is greater than one, it reassigns partition leadership to other brokers in the cluster. The broker is not eligible for partition leadership again until it is taken out of maintenance mode.
 

modules/upgrade/partials/rolling-upgrades/enable-maintenance-mode.adoc

@@ -102,10 +102,10 @@ The combination of the `--watch` and `--exit-when-healthy` flags tell rpk to mon
 [NOTE]
 ====
 ifdef::rolling-upgrade[]
-You can also evaluate xref:manage:monitoring.adoc[metrics] to determine cluster health. If the cluster has any issues, take the broker out of maintenance mode by running the following command before proceeding with other operations, such as decommissioning or retrying the rolling upgrade:
+You can also evaluate xref:manage:monitoring.adoc[metrics] to determine cluster health. If the cluster has any issues, take the broker out of maintenance mode by running the following command before retrying the rolling upgrade:
 endif::[]
 ifdef::rolling-restart[]
-You can also evaluate xref:manage:monitoring.adoc[metrics] to determine cluster health. If the cluster has any issues, take the broker out of maintenance mode by running the following command before proceeding with other operations, such as decommissioning or retrying the rolling restart:
+You can also evaluate xref:manage:monitoring.adoc[metrics] to determine cluster health. If the cluster has any issues, take the broker out of maintenance mode by running the following command before retrying the rolling restart:
 endif::[]
 
 ```bash