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/go/README.md

@@ -145,6 +145,14 @@ call returns a `StreamAlarmsClient`; cancel its context to terminate the
 stream. All three pass straight through to the gateway's central alarm
 monitor.
 
+`ActiveAlarmSnapshot.GetFromTruncatedSnapshot()` 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).
+
 ## Write Semantics And Common Pitfalls
 
 These are MXAccess parity behaviors that surprise new callers. The gateway