adjust hwm and apply code review

Author: paulohtb6

modules/manage/pages/disaster-recovery/shadowing/failover-runbook.adoc

@@ -128,6 +128,12 @@ Name: <topic-name>, State: ACTIVE
  1          2345     2579     2568     11
 ----
 
+The partition information shows:
+* **SRC_LSO**: Source partition Last Stable Offset
+* **SRC_HWM**: Source partition High Watermark  
+* **DST_HWM**: Shadow (destination) partition High Watermark
+* **Lag**: Message count difference between source and shadow partitions
+
 [IMPORTANT]
 ====
 Note the replication lag to estimate potential data loss during failover. The `Tasks` section shows the health of shadow link replication tasks. For details about what each task does, see xref:setup.adoc#shadow-link-tasks[].

modules/manage/pages/disaster-recovery/shadowing/monitor.adoc

@@ -53,7 +53,7 @@ The status output includes:
 * **Shadow link state**: Overall operational state (`ACTIVE`)
 * **Individual topic states**: Current state of each replicated topic (`ACTIVE`, `FAULTED`, `FAILING_OVER`, `FAILED_OVER`)
 * **Task status**: Health of replication tasks across brokers (`ACTIVE`, `FAULTED`, `NOT_RUNNING`, `LINK_UNAVAILABLE`). For details about shadow link tasks, see xref:setup.adoc#shadow-link-tasks[].
-* **Lag information**: Replication lag per partition showing source vs shadow watermarks
+* **Lag information**: Replication lag per partition showing source vs shadow high watermarks (HWM)
 
 [[shadow-link-metrics]]
 == Metrics
@@ -66,7 +66,7 @@ Shadowing provides comprehensive metrics to track replication performance and he
 
 |`redpanda_shadow_link_shadow_lag`
 |Gauge
-|The lag of the shadow partition against the source partition, calculated as source partition LSO minus shadow partition HWM. Monitor by `shadow_link_name`, `topic`, and `partition` to understand replication lag for each partition.
+|The lag of the shadow partition against the source partition, calculated as source partition LSO (Last Stable Offset) minus shadow partition HWM (High Watermark). Monitor by `shadow_link_name`, `topic`, and `partition` to understand replication lag for each partition.
 
 |`redpanda_shadow_link_total_bytes_fetched`
 |Count

modules/manage/pages/disaster-recovery/shadowing/setup.adoc

@@ -278,6 +278,8 @@ acl_filters:
 
 Consumer group filters determine which consumer groups have their offsets replicated to the shadow cluster by the <<consumer-group-shadowing-task,Consumer Group Shadowing task>>. By default, all consumer groups are replicated unless you specify filters.
 
+Offset replication operates selectively within each consumer group. Only committed offsets for active shadow topics are synchronized, even if the consumer group has offsets for additional topics that aren't being shadowed. For example, if consumer group "app-consumers" has committed offsets for "orders", "payments", and "inventory" topics, but only "orders" is an active shadow topic, then only the "orders" offsets will be replicated to the shadow cluster.
+
 [,yaml]
 ----
 consumer_offset_sync_options:
@@ -296,7 +298,7 @@ consumer_offset_sync_options:
 
 **Avoid name conflicts:** If you plan to consume data from the shadow cluster, do not use the same consumer group names as those used on the source cluster. While this won't break shadow linking, it can impact your RPO/RTO because conflicting group names may interfere with offset replication and consumer resumption during disaster recovery.
 
-**Offset clamping:** When Redpanda replicates consumer group offsets from the source cluster, offsets are automatically "clamped" during the commit process. If a replicated offset is above the high watermark (HWM) of the shadow partition, Redpanda clamps the offset to the shadow partition's HWM. This ensures offsets remain valid and prevents consumers from seeking beyond available data on the shadow cluster.
+**Offset clamping:** When Redpanda replicates consumer group offsets from the source cluster, offsets are automatically "clamped" during the commit process on the shadow cluster. If a committed offset from the source cluster is above the high watermark (HWM) of the corresponding shadow partition, Redpanda clamps the offset to the shadow partition's HWM before committing it to the shadow cluster. This ensures offsets remain valid and prevents consumers from seeking beyond available data on the shadow cluster.
 
 === Starting offset for new shadow topics