[fix][doc] Clarify subscription and consumer semantics under geo-replication

[codelipenghui]

Motivation

The geo-replication documentation can be read as if a single subscription could be actively consumed from several clusters at the same time. Pulsar does not support that: a subscription is local to the cluster in which it is created, and using the same subscription name in another cluster creates a separate, independent subscription that receives its own copy of the topic data. Only the mark-delete position of an opt-in replicated subscription is synchronized, and that feature targets failover, not active-active consumption.

PIP-33 states the behavior explicitly:

The only limitation is that subscriptions are currently 'local' to the cluster in which they are created. That is, no state for the subscription is transferred across regions.
If a consumer reconnects to a new region, it will trigger the creation of a new unrelated subscription, albeit with the same name.

The wording that caused the misreading:

• concepts-replication.md: "two consumers (C1 and C2) can consume those messages from their clusters" and "consumers can consume all messages from all data centers", both of which suggest one shared subscription spanning clusters.
• administration-geo.md: "subscriptions cannot only be local to the cluster where the subscriptions are created but also can be transferred between clusters after the replicated subscription is enabled". Subscriptions are never transferred; only the mark-delete position is replicated.
• administration-geo.md: "All messages produced in any of the three clusters are delivered to all subscriptions in other clusters", which also implies that subscriptions in a cluster do not consume locally produced messages.

Changes

docs/concepts-replication.md

• Add a section "Subscriptions and consumers across clusters" before "Replication mechanisms":
  • a table of what is and is not replicated across clusters (messages: yes; subscriptions including cursors, consumers, backlog and acknowledgment state: no, each cluster keeps its own; mark-delete position of a replicated subscription: yes, if explicitly enabled; individual acknowledgments: no);
  • Subscriptions are local to a cluster — the same subscription name in two clusters creates two independent subscriptions;
  • Consumers do not share the workload across clusters — every message is processed once per cluster, and splitting the load across regions must be done at the topic or partition level;
  • Replicated subscriptions: for failover, not for active-active consumption.
• Clarify the intro example and the active-active replication pattern so that consumers are no longer described as consuming from a single subscription.

docs/administration-geo.md

• Rewrite the "subscriptions can be transferred between clusters" sentence and the "delivered to all subscriptions in other clusters" sentence.
• Fix two stale anchors: #1-way-and-2-way-geo-replication → #1-way-unidirectional-and-2-way-bidirectional-geo-replication.

Versioned docs

The misleading text exists in released versions, so the change is propagated to the versioned docs:

• 5.0.x, 4.2.x, 4.0.x — applied with scripts/docs-tool.sh apply_changes_to_versioned_docs.
• 4.1.x, 3.3.x, 3.2.x, 3.1.x — these are no longer in the supported version list, but their pages are still published and contain the same text. The patch applies cleanly to 4.1.x; for the 3.x versions administration-geo.md does not contain the 1-way/2-way note (so the anchor hunk does not apply) and 3.1.x uses different image alt text, so the remaining changes were applied manually while preserving each version's own text.

The added section is byte-identical in docs/ and in all seven versioned docs.

Verification

• The new section is identical (4337 characters) across all eight files.
• All 116 relative markdown links in the 16 touched files resolve to an existing file and heading.
• No .rej/.orig files left behind.
• yarn build was not run locally (dependencies not installed); a preview of the new table would be worth a look.