chore(clients): regenerate for alarm truncation fields; READMEs note the degraded flag

Task 8 added ActiveAlarmSnapshot.from_truncated_snapshot = 16 and
QueryActiveAlarmsReplyPayload.snapshot_truncated = 2. Regenerate every
downstream binding from the canonical Contracts protos:

- client descriptor set (protoc 34.1 pin)
- Go (protoc-gen-go v1.36.11 / protoc-gen-go-grpc 1.6.2)
- Python (grpcio-tools 1.80.0 pin)
- Java (gradle generateProto)
- Rust vendored protos under clients/rust/protos, which build.rs falls back
  to for out-of-repo tarball builds and which must track Contracts

.NET needed no regeneration - the client compiles against the Contracts
Generated/ output already committed with the proto change. No client has a
typed wrapper model around ActiveAlarmSnapshot; all five pass the generated
type straight through, so codegen alone carries the field.

Each client README's alarm section gains a paragraph on the flag: the
snapshot set may omit actives and absence-implies-cleared inference was
suspended, so callers must not reconcile deletions from a truncated set.
Distinguished from the per-record 'degraded' subtag-fallback flag, which it
is easily confused with.

clients/rust/README.md

@@ -121,8 +121,16 @@ creates an authenticated `tonic` client and attaches `authorization: Bearer
 `close_session_raw`, `invoke_raw`, `stream_events`, `query_active_alarms`,
 `stream_alarms`, `acknowledge_alarm`, and `raw_client`. `stream_alarms`
 returns an `AlarmFeedStream` async stream of alarm-feed messages and
-shares the gateway's central alarm monitor with every other client. The
-session helpers keep MXAccess handles visible:
+shares the gateway's central alarm monitor with every other client.
+
+`ActiveAlarmSnapshot::from_truncated_snapshot` reports that the record came from
+a provider fetch which hit the per-fetch cap: the snapshot set may omit active
+alarms, and the gateway suspended its absence-implies-cleared inference for that
+poll. Treat the set as possibly incomplete rather than reconciling deletions
+from it. It is set-level degraded status, not a comment on the record's own
+fidelity, and is distinct from `degraded` (the subtag fallback provider).
+
+The session helpers keep MXAccess handles visible:
 
 ```rust
 let session = client.open_session(request).await?;

clients/rust/protos/mxaccess_gateway.proto

@@ -726,6 +726,13 @@ message AcknowledgeAlarmReplyPayload {
 // stream.
 message QueryActiveAlarmsReplyPayload {
   repeated ActiveAlarmSnapshot snapshots = 1;
+  // True when the provider fetch backing this reply came back holding the
+  // per-fetch cap (MxGateway:Alarms:MaxAlarmsPerFetch). The reply may then omit
+  // active alarms, and the worker suspends its absence-implies-Clear inference
+  // for that poll — so a reference missing from `snapshots` is not evidence the
+  // alarm cleared. Carried on the payload as well as per-record because a
+  // truncated fetch that filters down to zero records still has to say so.
+  bool snapshot_truncated = 2;
 }
 
 message MxEvent {
@@ -932,6 +939,16 @@ message ActiveAlarmSnapshot {
   // OnAlarmTransitionEvent.source_provider; always ALARMMGR or SUBTAG on the
   // wire (never UNSPECIFIED).
   AlarmProviderMode source_provider = 15;
+  // True when the provider fetch that produced this snapshot hit the per-fetch
+  // cap: the snapshot set may omit active alarms, and the worker suspended its
+  // absence-implies-Clear inference for that poll. Says nothing about THIS
+  // record's fidelity — the record is as accurate as any other; it flags that
+  // the set it belongs to is possibly incomplete. QueryActiveAlarms returns a
+  // bare `stream ActiveAlarmSnapshot` with no envelope message, so a per-record
+  // boolean is the only additive way to carry set-level degraded status on that
+  // RPC. Distinct from `degraded`, which is about the subtag fallback provider.
+  // Additive (proto3): clients that ignore it deserialize the stream unchanged.
+  bool from_truncated_snapshot = 16;
 }
 
 enum AlarmConditionState {