Loki HTTP client has no timeout — a stalled Loki endpoint blocks the status refresh indefinitely

[ooloth]

Current state

The Loki HTTP client in clients/src/loki.rs constructs reqwest::Client::new() with no explicit timeout configured. reqwest's default is no timeout, meaning a slow or unresponsive Loki server will block the status refresh indefinitely. Since the Loki fetch is part of the unified status pipeline, a single hung Loki connection stalls the entire refresh cycle — and the TUI — with no recovery until the upstream eventually closes the connection.

Ideal state

• The Loki entries function returns an Err within a bounded time when Loki is slow or unavailable.
• The timeout value is set deliberately (e.g. 10–30 s) using reqwest::ClientBuilder, not the reqwest default.
• A timeout error surfaces as a visible failure in the status result rather than an indefinite block.

Out of scope

• Retry logic for the Loki client (separate concern).
• Circuit breaking on persistent Loki failures.
• Timeout for the GitHub, Linear, or GCP clients (each tracked separately).

Starting points

• clients/src/loki.rs — reqwest::Client::new() at line ~51; the only Loki HTTP call site

QA plan

1. Read clients/src/loki.rs and confirm reqwest::ClientBuilder::new().timeout(Duration::from_secs(N)).build()? (or equivalent) is present — no bare reqwest::Client::new() remains.
2. Confirm the timeout Duration is a named constant or otherwise documented value, not a magic number.
3. Run just build and confirm it compiles cleanly.

Done when

The Loki HTTP client in clients/src/loki.rs is constructed with an explicit, deliberate timeout so a stalled Loki endpoint cannot block the caller indefinitely.