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
     }

clients/rust/tests/client_behavior.rs

@@ -14,6 +14,7 @@ use tokio::sync::{mpsc, Mutex};
 use tokio_stream::wrappers::{ReceiverStream, TcpListenerStream};
 use tonic::transport::Server;
 use tonic::{Request, Response, Status};
+use zb_mom_ww_mxgateway_client::error::ensure_mxaccess_success;
 use zb_mom_ww_mxgateway_client::generated::mxaccess_gateway::v1::mx_access_gateway_server::{
     MxAccessGateway, MxAccessGatewayServer,
 };
@@ -337,6 +338,57 @@ fn authentication_and_authorization_statuses_are_distinct_and_redacted() {
     assert!(!auth.to_string().contains("visible_secret"));
 }
 
+#[test]
+fn command_reply_validation_fixtures_branch_on_category_and_negative_hresult() {
+    // The shared behavior fixtures pin both reply-validation rules: a status
+    // entry fails iff its category is not OK (the raw `success` member is
+    // diagnostics only) and an HRESULT fails iff it is present and negative.
+    for (fixture, expect_failure) in [
+        ("register.ok.reply.json", false),
+        ("write.status-category-error-success-set.reply.json", true),
+        ("write.status-category-ok-success-zero.reply.json", false),
+        ("write.hresult-s-false.reply.json", false),
+        ("write.hresult-e-fail.reply.json", true),
+    ] {
+        let reply = command_reply_fixture(fixture);
+        let result = ensure_mxaccess_success(reply);
+
+        assert_eq!(
+            result.is_err(),
+            expect_failure,
+            "fixture {fixture} expected failure = {expect_failure}, got {result:?}"
+        );
+    }
+}
+
+#[test]
+fn status_entry_verdict_ignores_the_raw_success_member() {
+    // Edges the fixtures cannot express: an OK category always passes and an
+    // unspecified category always fails, whatever `success` carries.
+    for (category, success, expect_failure) in [
+        (MxStatusCategory::Ok, 0, false),
+        (MxStatusCategory::Ok, 1, false),
+        (MxStatusCategory::CommunicationError, 1, true),
+        (MxStatusCategory::Unspecified, 1, true),
+    ] {
+        let reply = MxCommandReply {
+            protocol_status: Some(ok_status("command ok")),
+            statuses: vec![MxStatusProxy {
+                success,
+                category: category as i32,
+                ..MxStatusProxy::default()
+            }],
+            ..MxCommandReply::default()
+        };
+
+        assert_eq!(
+            ensure_mxaccess_success(reply).is_err(),
+            expect_failure,
+            "category {category:?} with success {success} expected failure = {expect_failure}"
+        );
+    }
+}
+
 #[test]
 fn command_error_display_keeps_raw_reply_accessible() {
     let reply = mxaccess_failure_reply();
@@ -1358,6 +1410,52 @@ fn event(sequence: u64) -> MxEvent {
     }
 }
 
+/// Load a shared command-reply fixture into an [`MxCommandReply`].
+///
+/// The fixtures are protobuf JSON, which prost cannot parse directly, so this
+/// reads the fields the reply-validation rules actually consume (`hresult` and
+/// the status `success`/`category` pair) and rebuilds the message. Enum names
+/// resolve through the generated `from_str_name`, so a fixture naming a
+/// category the contract does not define fails the test rather than silently
+/// degrading to `Unspecified`.
+fn command_reply_fixture(file_name: &str) -> MxCommandReply {
+    let fixture = behavior_fixture(&format!("command-replies/{file_name}"));
+
+    let statuses = fixture["statuses"]
+        .as_array()
+        .map(Vec::as_slice)
+        .unwrap_or_default()
+        .iter()
+        .map(|status| {
+            let category_name = status["category"].as_str().unwrap();
+            MxStatusProxy {
+                success: status["success"].as_i64().unwrap() as i32,
+                category: MxStatusCategory::from_str_name(category_name)
+                    .unwrap_or_else(|| panic!("unknown status category {category_name}"))
+                    as i32,
+                detail: status["detail"].as_i64().unwrap_or_default() as i32,
+                diagnostic_text: status["diagnosticText"]
+                    .as_str()
+                    .unwrap_or_default()
+                    .to_owned(),
+                ..MxStatusProxy::default()
+            }
+        })
+        .collect();
+
+    MxCommandReply {
+        session_id: fixture["sessionId"].as_str().unwrap_or_default().to_owned(),
+        correlation_id: fixture["correlationId"]
+            .as_str()
+            .unwrap_or_default()
+            .to_owned(),
+        protocol_status: Some(ok_status("command ok")),
+        hresult: fixture["hresult"].as_i64().map(|hresult| hresult as i32),
+        statuses,
+        ..MxCommandReply::default()
+    }
+}
+
 fn behavior_fixture(path: &str) -> Value {
     let path = std::path::Path::new(env!("CARGO_MANIFEST_DIR"))
         .join("../proto/fixtures/behavior")