The local-provider probe used 1 s connect / 2 s total timeouts tuned for a
loopback ollama on `localhost:11434`. When the same provider points at a
remote reverse-proxy (e.g. Open WebUI under `https://host/ollama/v1`),
TLS handshake plus WAN latency routinely exceeds 2 s on cold connections,
flipping the catalog to `LocalOffline` and producing periodic
`Configured local provider offline` WARNs even though the upstream
ollama is healthy.

Pick the timeout pair from the base URL: loopback hosts keep the original
1 s / 2 s budget so a dead local daemon still surfaces fast; everything
else gets 3 s / 8 s — comfortable for cold TLS plus several WAN
round-trips. Unparseable URLs fall back to the loopback budget rather
than silently slowing every probe.

Also flatten reqwest's error cause chain in the WARN line so future
operators can see whether the failure was a timeout, DNS, TLS handshake,
or HTTP status — the default Display impl drops the inner cause.

reqwest renders timeouts as 'timed out' (no 'timeout' substring), so the
fallback's contains("timeout") check never matched and always appended
a redundant marker.

probe_provider built a fresh reqwest::Client on every call, throwing away
the connection pool and TLS sessions between cycles. With the relaxed
remote timeouts in place, every 60-second probe to an HTTPS reverse-proxy
front (Open WebUI, remote ollama) was paying a full ~1-2 s cold-start
TLS handshake — about 29 minutes of avoidable per-day latency per
provider, plus extra connection log noise upstream.

Hold the client in a process-wide OnceLock so the pool persists across
probe cycles. The client is built with the looser remote timeouts;
loopback callers tighten the total budget via per-request
`RequestBuilder::timeout(\`PROBE_TIMEOUT_SECS\`)`. connect_timeout
collapses to the remote 3 s value (reqwest cannot override it
per-request), but a localhost daemon that cannot accept TCP within 3 s
is already broken.

Limitation: cache is not invalidated on `[proxy]` config reload. The
motivating case — reverse-proxy URLs in `[provider_urls]` — does not
involve forward proxies, so this is acceptable until someone hits it.