docs(alarms): describe the real StreamAlarms open sequence, and close TST-16

The final integration review's non-blocker reservations, all documentation
or comment truth except one test arm.

The alarm feed opens provider_status -> snapshot_status -> cached
active_alarm -> snapshot_complete, which is what GatewayAlarmMonitor has
done since the snapshot_status frame landed. Two places still described
the old order: docs/Grpc.md said provider_status arrived *after* the
initial snapshot, contradicting its own snapshot_status section two
paragraphs down, and AlarmFeedMessage's leading proto comment named
neither status frame at all. Both now state the sequence the monitor
emits, so a client author reading either one gets the frame order right.

The proto comment change flows through the generated trees (Contracts,
Go, Java) and the client descriptor set; the Rust vendored copy stays
byte-identical to canonical. Python's generator does not carry proto
comments into its output, so it has no delta.

AlarmsHubPublisherTests' valueless-payload case covered snapshot_complete
and provider_status but not snapshot_status, leaving the newest arm
unpinned against the redaction switch that must ignore it. Added.

WnWrapAlarmConsumer's ack comment led with the 2026-05-01 reading that
-55 tracks the 8-arg overload, then refuted itself six lines later with
the 2026-08-18 probe. It now leads with the observation labelled as
narrower than it reads -- mirroring the correction already in
docs/AlarmClientDiscovery.md -- so the block argues one thing: the 6-arg
call site stays for parity, and rc semantics are per the probe. A
paragraph orphaned by an earlier splice is rewrapped. Comment interior
only; the file compiles on Windows.

TST-16 gets a dated closure note rather than a rewrite: the flag it
called dead was implemented 2026-08-18. GatewayDashboardDesign's /browse
paragraph gains the failed-read carve-out GatewayConfiguration already
documented, so the two agree that a failed read keeps its - placeholder.

docs/GatewayDashboardDesign.md

@@ -520,7 +520,9 @@ panel. The panel shows each subscribed tag's live value, MXAccess data type,
 quality and source timestamp, refreshed every two seconds — but the value column
 obeys `Dashboard:ShowTagValues` like every other dashboard value surface. With
 the flag false (the default) `DashboardLiveDataService` hands the page
-`[redacted]` in place of the formatted value; data type, quality, source
+`[redacted]` in place of the formatted value of each **successfully read** tag —
+a failed read keeps its `-` placeholder, since there was no value to suppress —
+while data type, quality, source
 timestamp and any read error are untouched, so the panel still answers "is this
 tag advising and healthy" without disclosing the value. The substitution happens
 at the service, not in the page: one decision point, and the value never enters

docs/Grpc.md

@@ -114,10 +114,11 @@ message AlarmProviderStatus {
 }
 ```
 
-The gateway emits `provider_status` once when a client first subscribes
-(immediately after the initial snapshot and before the first live transition)
-and again on every failover or failback. A late-joining client therefore
-always learns the current provider mode without waiting for the next switch.
+The gateway emits `provider_status` once when a client first subscribes — as
+the **first** frame on the stream, before the `snapshot_status` frame and
+before any cached `active_alarm` — and again on every failover or failback. A
+late-joining client therefore learns the current provider mode before it sees a
+single alarm, without waiting for the next switch.
 
 #### Snapshot completeness on the alarm feed