fix(CLI-37,CLI-38): make status/HRESULT reply validation conformant across all five clients

One cross-client conformance pass; also closes first-cycle CLI-08.

CLI-37: an MxStatusProxy entry is a failure iff `category !=
MX_STATUS_CATEGORY_OK`. The proto contract has always said so — `success` is
the raw 16-bit COM member carried verbatim for diagnostics, not a boolean — but
four clients branched on `success` alone and .NET required both, so the same
gateway reply produced opposite verdicts per language. An absent entry stays
success; a present entry with an UNSPECIFIED category is a failure, because the
worker always maps a category and an unmapped one is not proven OK.

CLI-38: a reply fails on HRESULT iff `hresult` is present and negative, so
positive COM success codes such as S_FALSE (1) pass. .NET/Go/Java used `!= 0`,
which errored on a parity-preserving S_FALSE that Python and Rust accepted.
This makes the existing ClientLibrariesDesign.md claim true rather than
rewriting the doc to describe the divergence.

Four shared fixtures pin both rules cross-client, and each language suite also
carries a table test for the two edges a fixture cannot express (absent entry,
UNSPECIFIED category). A Java test fake that built a status with a bare
`setSuccess(1)` and no category is fixed — under the category rule that reply
was never a success.

clients/rust/src/error.rs

@@ -308,10 +308,12 @@ pub fn ensure_command_success(reply: MxCommandReply) -> Result<MxCommandReply, E
 /// This is the second reply check applied to the typed command path, after
 /// [`ensure_command_success`] confirms the protocol envelope is `Ok`. It
 /// enforces MXAccess parity: a reply can carry an `Ok` protocol envelope while
-/// MXAccess itself rejected the operation. Following COM semantics (and the
-/// Python client), only a **negative** `hresult` is a failure — positive codes
-/// such as `S_FALSE = 1` are success. A `MXSTATUS_PROXY` entry is treated as a
-/// failure when its `success` member is `0`.
+/// MXAccess itself rejected the operation. Following COM semantics, only a
+/// **negative** `hresult` is a failure — positive codes such as `S_FALSE = 1`
+/// are success. A `MXSTATUS_PROXY` entry is treated as a failure when its
+/// `category` is not [`MxStatusCategory::Ok`]; the `success` member mirrors the
+/// raw COM value verbatim for diagnostics and never enters the verdict, so an
+/// entry with an unspecified category fails even when `success` is non-zero.
 ///
 /// Per-item bulk failures are reported inside each result entry
 /// (`was_successful = false`) rather than in the top-level `hresult`/`statuses`
@@ -320,10 +322,14 @@ pub fn ensure_command_success(reply: MxCommandReply) -> Result<MxCommandReply, E
 /// # Errors
 ///
 /// Returns [`Error::MxAccess`] when `reply.hresult` is negative or any
-/// `reply.statuses` entry reports a non-success `success` member.
+/// `reply.statuses` entry reports a category other than
+/// [`MxStatusCategory::Ok`].
 pub fn ensure_mxaccess_success(reply: MxCommandReply) -> Result<MxCommandReply, Error> {
     let hresult_failure = reply.hresult.is_some_and(|hresult| hresult < 0);
-    let status_failure = reply.statuses.iter().any(|status| status.success == 0);
+    let status_failure = reply
+        .statuses
+        .iter()
+        .any(|status| status.category != MxStatusCategory::Ok as i32);
 
     if hresult_failure || status_failure {
         Err(Box::new(MxAccessError::new(reply)).into())
@@ -412,8 +418,10 @@ mod tests {
         let mut reply = ok_reply();
         // Positive hresult (e.g. S_FALSE = 1) is a success, not a failure.
         reply.hresult = Some(1);
+        // A zero `success` member with an OK category is still a success: the
+        // category is authoritative and `success` is diagnostics only.
         reply.statuses = vec![MxStatusProxy {
-            success: 1,
+            success: 0,
             category: MxStatusCategory::Ok as i32,
             ..MxStatusProxy::default()
         }];
@@ -424,8 +432,9 @@ mod tests {
     #[test]
     fn ensure_mxaccess_success_flags_failing_status_entry() {
         let mut reply = ok_reply();
+        // A non-OK category fails even though the raw `success` member is set.
         reply.statuses = vec![MxStatusProxy {
-            success: 0,
+            success: 1,
             category: MxStatusCategory::CommunicationError as i32,
             detail: 42,
             diagnostic_text: "write rejected for mxgw_visible_secret".to_owned(),

clients/rust/src/value.rs

@@ -282,7 +282,11 @@ impl MxStatus {
         &self.raw
     }
 
-    /// `MXSTATUS_PROXY.Success` flag (0 = error, non-zero = good/warning).
+    /// Raw `MXSTATUS_PROXY.Success` member, carried verbatim from COM.
+    ///
+    /// This is a diagnostic value, not a verdict: the wire contract makes
+    /// [`Self::category`] authoritative, and `ensure_mxaccess_success` branches
+    /// on the category alone.
     pub fn success(&self) -> i32 {
         self.raw.success
     }