fix: [poc_2.6.17] stop CDC acting on stale topology changes; answer topology queries on unconfigured clusters

[czs007]

Cherry-picks onto poc_2.6.17 for a customer running this branch, so a single image carries
everything they need. Two fixes are open upstream against master (#52728, #52687); the other
two are already on 2.6 and are brought over because they bear on the same area.

#52728 — CDC stops itself on a topology change that predates the task

A replicator resumes from the checkpoint the target cluster reports, which after
milvus-backup restore secondary is the position the backup was taken at. Replaying from
there walks over every topology change made since — including ones that removed this edge
before it was re-created — and those were acted on as if they were current:

• the replicator deleted its own replicating-pchannel/ key and stopped 0.2 s after
  starting;
• the same message, forwarded to the secondary, made it a standalone primary again, dropping
  its replicate checkpoint.

Nothing recovered from it: the topology query still reported the edge (only the per-pchannel
task keys were gone), and re-applying the same configuration was short-circuited as unchanged
and returned success.

ReplicatePChannelMeta.initialized_checkpoint already carries the time tick of the
AlterReplicateConfig that created the task, so a message at or before it predates the task
and cannot be an instruction for it. It is now disregarded both when deciding to remove the
task and when deciding to forward the message. A task with no initialized time tick keeps the
previous behaviour.

#52687 — topology query on a cluster with no replication blocks

GetReplicateConfiguration never returned on a cluster that had never been given a replicate
configuration — the state of every freshly installed cluster. Such a cluster reports a nil
configuration, and the watcher's wait condition treated the resulting nil helper as "no
assignment received yet", so the call ran to the caller's deadline and surfaced as
DEADLINE_EXCEEDED, indistinguishable from an unhealthy cluster.

Wait only until an assignment has been received and return the possibly-nil helper; make the
ConfigHelper read accessors nil-receiver safe; reject replicate messages explicitly on a
cluster with no configuration, which previously could not be reached because the lookup
blocked first.

Tests

Both upstream PRs' unit tests are included. internal/cdc/util had no test file before:

• ordering check in both directions, including the no-initialized-time-tick case that keeps
  the old behaviour;
• a current detach still removes the replication, a detach that predates the task does not;
• the consume loop neither forwards a stale topology change nor ends on it.

Also picked from 2.6

• fix: [cp 2.6] recover pchannels from collection metadata #51144 — recover pchannels from collection metadata (51749e6f8d). streamingcoord
  recovery adds WAL topics missing after stats initialization by reading them back from
  RootCoord collection metadata. Directly relevant here: the customer reinstalled the
  secondary, and recovery on a rebuilt cluster is exactly this path.
• fix: [cp2.6]correct the CDC replication lag metric #51365 — correct the CDC replication lag metric (e6b5d9308d). The replication lag
  series was wrong, so the one signal an operator would watch to notice replication had
  stopped could not be trusted. Given the failure this branch fixes is otherwise silent, the
  metric being correct matters.

Both apply cleanly; the only conflict was two tests appended to the same file, resolved by
keeping both.

#50849 — ignore stale replicated txn body was checked and is already present on
poc_2.6.17. #51454 — skip unreplicable replicated ddl is on master only and depends on
message-property changes that are not on 2.6; it is left for a regular cherry-pick to 2.6
rather than being adapted here.

[sre-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from czs007 after the PR has been reviewed.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment