v0.8.63: Split runtime_api.rs by API domain and stabilize handler ownership

[Hmbown]

Problem

crates/tui/src/runtime_api.rs combines many API domains in one file:

• sessions
• threads
• tasks
• fleet
• agent runs
• automations
• skills
• MCP
• auth/mobile/runtime helper surfaces

It also mixes request/response types, route registration, route handlers, and manager lifecycle choices. The analysis noted inconsistent lifecycle patterns: some managers are shared through Arc, while others are instantiated per request.

There is also fragile error classification in places that match error.to_string().contains("not found").

Proposed shape

Split into a runtime API module family:

• runtime_api/mod.rs
• runtime_api/types.rs
• runtime_api/auth.rs
• runtime_api/sessions.rs
• runtime_api/threads.rs
• runtime_api/tasks.rs
• runtime_api/fleet.rs
• runtime_api/agent_runs.rs
• runtime_api/automations.rs
• runtime_api/skills.rs
• runtime_api/mcp.rs
• runtime_api/mobile.rs

Exact names can be adjusted to the existing route structure.

Acceptance criteria

• Route registration remains centralized and easy to audit.
• Each API domain owns its handlers and request/response types where practical.
• Shared app state / manager lifecycle is made explicit and consistent.
• String-matching error classification is replaced with typed/domain errors where touched.
• Existing API tests pass.
• Wire compatibility is preserved unless explicitly called out in a linked issue.

Risk

Medium. Route behavior and manager lifecycle are user-facing indirectly, so split this in small PRs.

[Hmbown]

Part of #3306.

Release-risk note: this is targeted at v0.8.63, but PRs should stay small and preserve behavior unless the issue explicitly calls out a behavior change.