Rust API: `Client::new` ignores `base_url` argument and silently routes requests to default localhost

[cferrys]

Summary

The Rust client constructor currently ignores its required base_url parameter, causing requests to use http://localhost:9200 unless options["base_url"] is set. This creates silent misrouting, especially in multi-node/staging/production setups.

Context

In etc/api/rust/src/client.rs:30, the constructor signature is pub fn new(_base_url: &str, options: Option<HashMap<String, String>>), but _base_url is never used.
The actual URL comes from Config::merge_defaults(options) and defaults to localhost (etc/api/rust/src/utils/config.rs:37, etc/api/rust/src/utils/config.rs:41).
This conflicts with documented behavior in etc/api/rust/README.md:97 and etc/api/rust/README.md:101, which states base_url is required and used by Client::new(base_url, options).
Current Rust API tests also pass base_url (etc/api/tests/test_health.rs:69, etc/api/tests/test_health.rs:72) but do not assert that it is actually honored.

Proposed Implementation

1. Update Client::new to use the base_url argument as the canonical source.
2. Keep backward compatibility by resolving precedence explicitly:
   • Recommended: base_url argument overrides options["base_url"] (or deprecate options["base_url"]).
3. Normalize and validate the resolved URL once, then pass it to Request::new.
4. Add regression tests that fail today:
   • A unit/integration test with a non-default URL proving requests do not target localhost.
   • A precedence test for base_url vs options["base_url"].
5. Update README and examples to match final precedence rules.

Impact

Fixing this prevents accidental writes/reads against the wrong node and restores trust in the Rust API contract.
For users supplying only Client::new(base_url, ...), this is a correctness fix with potentially 100% request-target mismatch today. It is especially high-impact for distributed deployments, CI, and production safety.