fix(namespace): reload rotated mTLS certificates in the REST client

[maswin]

Problem

Trino x Lance plugin started throwing CertificateExpired exception when trying to talk to iceberg rest catalog and the certs in trino co-ordinator instance got rotated.

RestNamespace::from_builder reads the mTLS certificate, key and CA once at construction
and bakes them into a single long-lived reqwest::Client. A reqwest::Identity cannot be
hot-swapped inside a live client, so the process keeps presenting the certificate it read at
startup forever.

Any environment that rotates short-lived certificates on disk therefore breaks once the
loaded certificate passes its notAfter. The server rejects the handshake and the client
sees a received TLS alert:

reqwest::Error { kind: Request, url: "https://<catalog-host>:7004/api/lance/<ns>/v1/namespace/%24/list?delimiter=%24",
  source: hyper::Error(Io, Custom { kind: InvalidData, error: "received fatal alert: CertificateExpired" }) }

(received matters: the peer is rejecting our client cert. A stale CA bundle or bad server
cert would surface locally as InvalidCertificate(Expired) / UnknownIssuer.)

Fix

RestClient now holds the client in an ArcSwap<reqwest::Client> and hands it out by value
(cheap — reqwest::Client is a handle around an Arc). Alongside it, the cert/key/CA paths,
the digest of the last-loaded content and the last-checked Instant are kept so the client
can be rebuilt.

The check is lazy, on the request path, gated by an interval:

• If the interval has elapsed, the PEM files are re-read and the client is rebuilt only if
  the content changed. Content, not mtime: rotation is often a symlink swap or an atomic
  rename. A digest keeps the comparison cheap without retaining private key bytes.
• Rebuilding drops the connection pool, which is correct (pooled connections were
  authenticated with the old certificate) and exactly why it is gated on a real change.
• Material that fails to read or build keeps the current client and retries on the next
  check, so a truncated read mid-rotation can't replace a working identity with one the
  server would reject.
• No background thread or task. A few-KB std::fs::read at most once per interval.
• arc-swap was already a workspace dependency; no new dependencies.

New property tls.reload_interval_seconds, parsed alongside the other tls.* keys, with a
matching builder setter. 0 disables reloading. Properties pass through the Python and Java
bindings opaquely, so both pick this up without binding changes; the tls.* list in
RestNamespace's javadoc is updated.

Verification

cargo build -p lance-namespace -p lance-namespace-impls --features rest -p lance
cargo test -p lance-namespace-impls --features rest
cargo fmt --all
cargo clippy --all --tests --benches -- -D warnings

[lance-gatekeeper]

⚠️ Gate recommendation: approve with a non-blocking risk.

The request-path reload, content fingerprinting, last-known-good fallback, and atomic client swap address the stale-identity root cause without replaying requests. The implementation also rejects mismatched certificate/key generations before publication.

The remaining risk is verification breadth: current tests prove that rotated PEM content rebuilds the client, but they do not exercise a peer-observed mTLS handshake, CA-only rotation, or a concurrent cutover. A local mTLS rotation test would make that operational contract durable.