fix(client/rust): handle provider_status arm (build break); real system-roots TLS; design doc (Client.Rust-030..032)

clients/rust/README.md

@@ -81,11 +81,19 @@ cargo run -p mxgw-cli -- smoke --endpoint https://mxgateway.example.local:5001 -
 The gateway can auto-generate its own self-signed certificate (it has no PKI).
 Unlike the other clients, the Rust client is **not** lenient: tonic 0.13.1
 exposes no public hook to inject a custom certificate verifier, so TLS over Rust
-is pin-only. A TLS connection requires either `--ca-file` /
-`ClientOptions::with_ca_file(...)` to pin a CA (export the gateway's self-signed
-certificate and pin it), or `--require-certificate-validation` /
-`with_require_certificate_validation(true)` to verify against the system trust
-roots. TLS with neither set fails `connect` with a clear, actionable error rather
+cannot accept an *arbitrary* self-signed certificate. A TLS connection requires
+one of two trust paths:
+
+- `--ca-file` / `ClientOptions::with_ca_file(...)` to pin a CA (export the
+  gateway's self-signed certificate and pin it). This is the path for a
+  self-signed gateway.
+- `--require-certificate-validation` / `with_require_certificate_validation(true)`
+  to verify against the operating system's trust roots (`tls-native-roots`). This
+  only succeeds for a certificate that chains to a root the host already trusts —
+  i.e. a gateway fronted by a publicly- or enterprise-CA-issued certificate, not a
+  bare self-signed one.
+
+TLS with neither set fails `connect` with a clear, actionable error rather
 than accepting the certificate. See
 [Gateway Configuration](../../docs/GatewayConfiguration.md#automatic-self-signed-certificate).