Refactor runtime and engine integration code

[chaqchase]

Summary

The runtime/engine layer is starting to sprawl. We now have Sentinel, Codex, and Claude as first-class engines, and we're also tracking follow-up work for Cursor, Gemini, Copilot, and Droid. Before we keep adding more adapters, it would be worth tightening up the current architecture so new runtimes plug into a cleaner surface.

Why this is worth doing

• A lot of the runtime logic is clearly following the same shape, but we still have engine-specific code paths scattered across enums, router responses, persisted thread state, settings UI, composer helpers, and runtime detection.
• Codex and Claude already duplicate parts of runtime discovery and status plumbing, which will get harder to maintain as more engines land.
• A cleanup pass now should make the next round of engine work faster and reduce the risk of platform-specific regressions.

Current pain points

• Engine registration is spread across multiple places instead of living behind one obvious contract.
• Runtime discovery/status logic is engine-specific even when the behavior is structurally the same.
• Thread state persistence is currently shaped around special cases (codex, claude, repo) rather than a more extensible engine/session model.
• UI code still has places that effectively special-case the current engine set instead of iterating over a richer engine definition.
• Status presentation helpers are already thin wrappers around duplicated runtime logic.

High-level implementation overview

1. Define a clearer engine adapter contract under src/lib/ai/chat/engines/ for capabilities like detection, status, model listing, session lifecycle, persistence needs, and user-facing setup errors.
2. Move engine registration into a single registry so routers and UI can derive from the same source of truth instead of hand-encoding engine lists in multiple places.
3. Refactor persisted engine state in src/lib/ai/chat/engines/types.ts and related persistence helpers so new engines can add session metadata without forcing another round of one-off schema branching.
4. Collapse duplicated runtime status/detection utilities where possible, especially around binary lookup, PATH handling, cached status snapshots, and availability messaging.
5. Update the settings/composer surfaces to render from engine metadata instead of hard-coded Codex/Claude branches.
6. Back the refactor with tests that lock down the registry contract, persistence format, and engine status/model loading behavior.

Acceptance criteria

• Adding a new external engine no longer requires touching a long chain of unrelated files just to get basic registration and status support.
• Runtime detection and status plumbing share common helpers where the behavior is actually the same.
• UI surfaces derive from engine metadata/registry instead of bespoke per-engine conditionals where practical.
• Existing Sentinel, Codex, and Claude behavior remains unchanged from a user perspective.
• Test coverage improves around engine registration, persistence, and runtime status handling.

References

• src/lib/ai/chat/engines/codex-cli.ts
• src/lib/ai/chat/engines/claude-sdk.ts
• src/lib/ai/chat/engines/types.ts
• src/server/api/routers/engines.ts
• src/components/chat/chat-composer-helpers.ts