fix(CLI-03): Rust typed invoke validates HRESULT/MXSTATUS_PROXY

Typed write/command wrappers now call ensure_mxaccess_success after
ensure_command_success, failing on hresult < 0 (COM-correct, matching
CLI-08/Python) or any MxStatusProxy.success == 0, via a new boxed
Error::MxAccess variant with credential-safe formatting. The raw invoke
escape hatch stays unvalidated.

archreview: CLI-03 (P0). Verified: cargo fmt/check/test (28) and clippy --all-targets -D warnings clean.

clients/rust/README.md

@@ -125,6 +125,18 @@ preserving the raw message for parity diagnostics. Command replies whose
 protocol status is not `PROTOCOL_STATUS_CODE_OK` become `Error::Command` and
 retain the raw `MxCommandReply`.
 
+The typed command helpers (`register`, `add_item`, `write`, the bulk variants,
+etc.) also enforce MXAccess parity on an otherwise-OK reply: a reply that
+reports a negative `hresult` (COM failure semantics — a positive code such as
+`S_FALSE = 1` is a success) or a non-success `MXSTATUS_PROXY` status entry
+becomes `Error::MxAccess`, which boxes an `MxAccessError` retaining the raw
+`MxCommandReply` (recover it with `MxAccessError::reply` / `into_reply`). Its
+message summarizes the `hresult` and status entries with credential-safe
+redaction. Per-item bulk failures are reported inside each result entry
+(`was_successful = false`) and do not raise `Error::MxAccess`. The raw
+`invoke_raw` / `client.invoke_raw` escape hatch performs neither check and
+returns the unvalidated reply.
+
 ## Write Semantics And Common Pitfalls
 
 These are MXAccess parity behaviors that surprise new callers. The gateway