Resolve Contracts-002 code-review finding

MxCommandReply.payload has no by-name ack case: MX_COMMAND_KIND_ACKNOWLEDGE_
ALARM_BY_NAME reuses the acknowledge_alarm reply payload. Verified the worker
(MxAccessCommandExecutor.ExecuteAcknowledgeAlarmByName) and gateway
(WorkerAlarmRpcDispatcher) already implement this correctly — the gap was
purely undocumented contract asymmetry. Documented the reuse on the proto
oneof case and the AcknowledgeAlarmReplyPayload message comment (regenerating
the .NET contract), and in docs/AlarmClientDiscovery.md. Added
ProtobufContractRoundTripTests.MxCommandReply_AcknowledgeAlarmByName_Reuses
AcknowledgeAlarmPayloadCase to pin the contract.

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

docs/AlarmClientDiscovery.md

@@ -762,6 +762,20 @@ in the codebase for the forward-compat shape, but the gateway-side
 `AcknowledgeAlarmByName` when the public RPC supplies a recognizable
 `Provider!Group.Tag` reference.
 
+**Command/reply payload reuse.** `MxCommand.payload` has a dedicated
+`acknowledge_alarm_by_name_command` field, but `MxCommandReply.payload`
+intentionally has **no** by-name-specific case. The by-name ack carries
+no outcome detail beyond the native return code, so the worker's
+`ExecuteAcknowledgeAlarmByName` sets the same `acknowledge_alarm`
+(`AcknowledgeAlarmReplyPayload`) reply case used by the GUID arm, with
+`native_status` = the `AlarmAckByName` return code (also echoed into the
+top-level `MxCommandReply.hresult`). Reply consumers must dispatch on
+`MxCommandReply.kind` (`MX_COMMAND_KIND_ACKNOWLEDGE_ALARM` vs.
+`MX_COMMAND_KIND_ACKNOWLEDGE_ALARM_BY_NAME`), not on the payload oneof
+case, to distinguish the two acks. `WorkerAlarmRpcDispatcher` reads only
+the top-level `hresult`/`protocol_status`, so it handles both arms
+without unpacking the payload.
+
 ### 5. STA / threading — production fix needed
 
 The wnwrap COM is `ThreadingModel=Apartment`. The consumer's