docs(GWC-26): record alarm feed repairs as at-least-once; share the channel worker fake

Code-review follow-up on fix/gwc-26-27-alarm-attach.

ApplyReconcile's snapshot-derived feed repairs are at-least-once, not
exactly-once: a reconcile reads the worker's current state while the matching
live transition may still be buffered in the monitor's lease, so both broadcast
and the duplicates are indistinguishable on the alarm feed. This pre-dates the
acked-state delta — the Raise/Clear presence repair has always had it, since
nothing serializes a reconcile pass against the in-flight live stream — so
closing it (serialization or timestamp dedup) stays out of scope for a P2 fix.
Documented instead, with the consumer contract stated explicitly (apply
transitions idempotently, never as an increment or toggle):

- ApplyReconcile gains a "Delivery semantics" comment.
- gateway.md softens the "defense in depth" prose to state the semantics.
- docs/Sessions.md carries the same caveat on the alarm-feed description.
- Tracker change-log records it as a known pre-existing characteristic and a
  candidate finding for the next review cycle.

Also hoists the ChannelWorkerClient fake — duplicated across the three alarm
test files — into TestSupport/, dropping the usings it took with it.

gateway.md

@@ -161,13 +161,22 @@ subscribers registered at fan-out time, so attaching after the subscribe +
 reconcile round trips would drop every transition raised in that window —
 including an `Acknowledge`, which the presence-only reconcile deltas would never
 repair. Transitions arriving during the window buffer in the lease's bounded
-channel instead. As defense in depth for any window this ordering cannot cover
-(worker restart, internal-subscriber overflow disconnect), a reconcile that finds
-a known alarm now reported `ActiveAcked` broadcasts an `Acknowledge` transition on
-the alarm feed. That is a feed-level repair rebuilt from the worker's own
-snapshot on the `StreamAlarms` surface — it is not an `MxEvent` and never reaches
+channel instead. As a backstop for any window this ordering cannot cover (worker
+restart, internal-subscriber overflow disconnect), a reconcile that finds a known
+alarm now reported `ActiveAcked` broadcasts an `Acknowledge` transition on the
+alarm feed. That is a feed-level repair rebuilt from the worker's own snapshot on
+the `StreamAlarms` surface — it is not an `MxEvent` and never reaches
 `StreamEvents`, so the "never synthesize events" rule is untouched.
 
+**Feed repair transitions are at-least-once, not exactly-once.** A reconcile reads
+the worker's current state while the corresponding live transition may still be
+buffered in the monitor's lease, so both can broadcast and the two are
+indistinguishable on the feed. This applies to the acked-state delta and equally
+to the older Raise/Clear presence repair: nothing serializes a reconcile pass
+against the in-flight live stream. Alarm-feed consumers (`StreamAlarms` clients
+and the dashboard alarm hub) must apply transitions idempotently — treat one as
+"set this alarm to this state", never as an increment or a toggle.
+
 ### Alarm providers and failover
 
 The alarm feed has two providers, both implemented worker-side: