fix(runtime): the passive half of a LocalDb pair stands its alarm drain down for its mesh partner (review R6 MINOR-4)

The drain gate's 'is my queue-sharing peer Primary?' used only the host of
LocalDb:Replication:PeerAddress, which the passive half (ApiKey +
SyncListenPort) does not set - so as Secondary it kept draining beside its
Primary partner and every alarm event reached the historian twice.
DriverHostActor takes a sharesAlarmQueueWithLocal predicate used when no
peer host is known; WithOtOpcUaRuntimeActors builds it
(BuildAlarmQueuePeerPredicate) for a SharesRowsWithPeer node with no
PeerAddress as 'a member of my own cluster-{ClusterId} mesh other than
me'. A node sharing no rows, or with no mesh role, gets none and keeps
draining. AlarmHistorian.md / Redundancy.md / pair-replication runbook
updated.

Claude-Session: https://claude.ai/code/session_01Ef2ozxS7QPanGT8uoATbTe

docs/operations/2026-07-20-localdb-pair-replication.md

@@ -94,7 +94,10 @@ Replication has two knobs, both under `LocalDb`:
 > the passive node has no `PeerAddress`; `SyncListenPort` is deliberately not part of it, since a
 > port with no key is fail-closed and syncs with nobody). The alarm-historian drain gate uses the
 > stricter `ApiKey` AND (`PeerAddress` OR `SyncListenPort > 0`) — so set the key **and** the port/peer
-> together, or the node keeps draining its own queue. Consequences at enablement time:
+> together, or the node keeps draining its own queue. Once gated, the passive half stands down for
+> its **per-cluster mesh partner** (it has no `PeerAddress` to name one) — so it must carry the pair's
+> `cluster-{ClusterId}` role, or as Secondary it keeps draining beside its Primary and the historian
+> gets every alarm event twice (review R6 MINOR-4). Consequences at enablement time:
 >
 > - A configured node registers with **`baselineExistingRows: true`**, so the rows **already in the
 >   file** are seeded into the row-version ledger at the LWW floor (HLC `0`) and actually travel.