feat(alarms): feed-level snapshot_status truncation frame on StreamAlarms

docs/DesignDecisions.md

@@ -203,7 +203,7 @@ Consequences, and how this sits with the existing failover/reconcile design:
   separately — see the next decision. A galaxy that truncates persistently
   is a configuration problem: raise `MxGateway:Alarms:MaxAlarmsPerFetch`.
 
-### Alarms — truncation is reported per record on the public snapshot stream
+### Alarms — truncation is reported per record on the snapshot stream, as a status frame on the live feed
 
 Decision (2026-08-17): the truncated-fetch verdict above is carried to clients as
 `QueryActiveAlarmsReplyPayload.snapshot_truncated` on the worker IPC reply and as
@@ -239,6 +239,23 @@ sub-cap fetch clears it, and `GatewayAlarmMonitor.ClearCache` drops it with the
 cache generation it describes. A caveat that never turns off is a caveat
 operators learn to ignore.
 
+The **live feed carries the verdict as set-level status**, not per record.
+`StreamAlarms` has an envelope — `AlarmFeedMessage` — so the shape forced on
+`QueryActiveAlarms` above is not forced here: the feed gets a fifth oneof case,
+`snapshot_status` (`AlarmSnapshotStatus.truncated`), alongside `provider_status`.
+The two carriers are therefore deliberately different shapes for the same verdict,
+and each is the only additive option on its own surface. Emission is
+**edge-triggered**, for the same reason the flag is not latched: a status frame
+repeated on every reconcile is noise a consumer filters out, and a filtered-out
+signal is no signal. The exception is the open-time frame, which is
+unconditional — a late joiner cannot distinguish "not truncated" from "this
+gateway does not send the frame" by silence, so it is told explicitly. It is
+ordered after `provider_status` and before the cached `active_alarm` frames so a
+consumer applying the snapshot as it streams holds the caveat while it applies
+the records it qualifies. A monitor restart's `ClearCache` emits the clearing
+frame as well: feed subscribers outlive the monitor's worker session, so a silent
+re-seed would leave them caveating a set that is no longer truncated.
+
 This is gateway metadata about **our** fetch mechanics, not a claim about MXAccess
 behaviour, so it is not a parity deviation: no event is synthesized and no
 MXAccess-observable semantics change.