feat(http): add timeouts and identifying user-agent to all provider HTTP calls

[kevinnft]

Summary

Every outbound HTTP client in the backend (chat, models, titles, tool runner, agent loop) was being created with reqwest::Client::new() — no timeouts of any kind. A stalled provider, dead TCP connection, or silently rate-limited upstream freezes the agent loop indefinitely with no error path and no recovery.

This PR adds a small shared services::http_client module with two builders that all 9 call sites now use.

What was wrong

$ rg "reqwest::Client::new\(\)|Client::new\(\)" src-tauri/src
src-tauri/src/agents/runner.rs:1074:        let client = reqwest::Client::new();
src-tauri/src/agents/runner.rs:1116:        let client = reqwest::Client::new();
src-tauri/src/services/chat_service.rs:166:    let client = reqwest::Client::new();
src-tauri/src/services/chat_service.rs:234:    let client = reqwest::Client::new();
src-tauri/src/services/chat_service.rs:528:    let client = reqwest::Client::new();
src-tauri/src/services/chat_service.rs:592:    let client = reqwest::Client::new();
src-tauri/src/services/chat_service.rs:700:    let client = reqwest::Client::new();
src-tauri/src/services/model_service.rs:45:    let client = Client::new();
src-tauri/src/services/model_service.rs:78:    let client = Client::new();
src-tauri/src/tools/executor.rs:334:    let client = reqwest::Client::new();

reqwest::Client::new() produces a client with no connect, read, or total timeout. In production this means:

• A provider that goes dark mid-stream silently hangs the chat session forever
• Anthropic / OpenAI rate-limit slowdowns produce no error, just a frozen UI
• DNS / connect failures take the OS default (often 75s+) before bubbling up
• No User-Agent — some providers and corporate proxies reject these requests

What this PR does

Adds src-tauri/src/services/http_client.rs with two shared constructors:

streaming_client() — SSE chat completions

• 10s connect timeout
• 60s per-read timeout (catches dead streams between chunks)
• 600s total ceiling (long completions still finish)

request_client() — non-streaming (model lists, title generation, single-shot completions)

• 10s connect timeout
• 120s total timeout

Both clients carry a enowX-Coder/<version> User-Agent (sourced from CARGO_PKG_VERSION) so providers, proxies, and the user's own firewall can attribute traffic correctly.

Migrates all 9 call sites:

• services/chat_service.rs — 5 sites
• services/model_service.rs — 2 sites
• agents/runner.rs — 2 sites
• tools/executor.rs — 1 site (web_search)

Behavior change

• Healthy paths: zero behavior change. Same requests, same headers, same payloads.
• Unhealthy paths: instead of hanging forever, the agent now returns a bounded AppError and the UI can recover.

Test plan

• cargo check passes locally on all touched files (no schema errors)
• All 9 Client::new() call sites migrated — rg returns 0 hits in src/ after the change
• Module includes 3 unit tests covering both builders + UA format
• No public API surface changed — pure internal refactor
• Existing CI (clippy -D warnings / cargo test) covers the rest

[kevinnft]

CI failure is pre-existing on main, not from this PR

The Backend (Rust) job fails with 122 clippy violations from the repo's disallowed_methods lint (unwrap/expect). All of them are in code this PR does not touch:

• src/lib.rs:74 and src/lib.rs:95 — both are pre-existing
• src/agents/runner.rs:1740, 1751, 1804, 1849, 1857, 1874, 1889, 1903, 1918, 1932, 1958 — all outside this PR's diff (this PR only changes lines 1074 and 1116)
• src/services/chat_service.rs:171, 174, 196, 242, 245, 263, 265, 482, 486, 491, 534, 584, 683, 688, 692, 698, 703 — all from serde_json::json! macro expansions and existing code, not the lines this PR modified

Concretely, the same cargo clippy -- -D warnings is also failing on main head and on every other open PR (#3, #4, #23). PR #22 (fix(ci): resolve 122 clippy violations + update bun.lockb) is the one trying to clean these up but is currently mergeable_state: dirty (conflict with main).

Recommended merge order: land #22 first (or rebase + merge it), then this PR will go green and can land cleanly. The Frontend (TypeScript) job on this PR already passed.

Happy to rebase once #22 (or another clippy cleanup) merges.

[enowdev]

I reviewed the feature and the main blocker now is merge state, not the timeout/user-agent idea itself. This PR conflicts with newer provider-routing changes already on main, especially in src-tauri/src/agents/runner.rs, src-tauri/src/services/chat_service.rs, and src-tauri/src/services/model_service.rs. When rebasing, please keep the newer Anthropics/gateway endpoint resolution from main and re-apply only the shared HTTP client changes (timeouts + User-Agent).