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

@@ -115,6 +115,13 @@ messages from the gateway's central monitor), and
 and ack target). Cancel the surrounding task or `aclose()` the iterator to
 terminate the stream.
 
+`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).
+
 Canceling a Python task cancels the client-side gRPC call or stream wait. It
 does not abort an in-flight MXAccess COM call inside the worker process.