Resolve Contracts-001/004/005/006/007/008 code-review findings

Contracts-001: docs/Grpc.md still described "four MxAccessGateway RPCs" —
updated to the actual six (adding AcknowledgeAlarm and QueryActiveAlarms to
the handler and validation-rule sections).

Contracts-003 (Won't Fix): the finding is factually wrong — the <Protobuf>
item for mxaccess_worker.proto already sets ProtoRoot="Protos"; all three
items are consistent (confirmed back to the reviewed commit).

Contracts-004: corrected the stale GatewayContractInfo XML summary
("before generated protobuf contracts are introduced").

Contracts-005: no proto field/enum value was ever removed, so no reserved
ranges were invented. Added a wire-compatibility policy comment to all three
.proto files instructing future editors to reserve removed numbers.

Contracts-006: documented MxStatusProxy.success — it mirrors the COM
MXSTATUS_PROXY numeric success member, is not a boolean, and clients should
branch on category.

Contracts-007: added 13 round-trip tests covering galaxy_repository.proto
messages, bulk-subscribe payloads, and raw-value/IPC worker bodies.

Contracts-008: WorkerAlarmRpcDispatcher never assigns AcknowledgeAlarmReply.
status, so the old "native status" proto comment was misleading. Corrected
the hresult/status proto comments and documented the worker native_status →
public reply mapping in AlarmClientDiscovery.md.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

docs/AlarmClientDiscovery.md

@@ -776,6 +776,28 @@ case, to distinguish the two acks. `WorkerAlarmRpcDispatcher` reads only
 the top-level `hresult`/`protocol_status`, so it handles both arms
 without unpacking the payload.
 
+**Worker `native_status` → public `AcknowledgeAlarmReply` mapping.** The
+worker carries the ack outcome as a single `int32`
+(`AcknowledgeAlarmReplyPayload.native_status`, the `AlarmAckByName` /
+`AlarmAckByGUID` return code; `0` = success), also mirrored into the
+worker `MxCommandReply.hresult`. The public `AcknowledgeAlarmReply` has
+two outcome-shaped fields, but only one is populated:
+
+- `AcknowledgeAlarmReply.hresult` — `WorkerAlarmRpcDispatcher` copies the
+  worker's `MxCommandReply.hresult` (the native return code) into this
+  field. **This is the authoritative ack-outcome field**; `0` means the
+  ack succeeded. It is absent only when the worker reply omitted the
+  value, which is a protocol violation surfaced in `protocol_status`.
+- `AcknowledgeAlarmReply.status` (`MxStatusProxy`) — the worker by-name /
+  by-GUID ack path produces only the `int32` return code, never a
+  populated `MXSTATUS_PROXY` struct, so `WorkerAlarmRpcDispatcher` leaves
+  this field **unset on every reply**. It is reserved for a future
+  structured view of the ack outcome. Clients must not depend on it.
+
+Client authors should therefore branch on `protocol_status` first (for
+transport/session-level failures) and then on `hresult` (`0` = ack
+accepted by MXAccess) — never on `status`.
+
 ### 5. STA / threading — production fix needed
 
 The wnwrap COM is `ThreadingModel=Apartment`. The consumer's