app-server cannot run a turn: make it a client of the runtime API, or link the extracted engine

From the 0.9.14 refactor backlog (codewhale-ops, 2026-09-11 recon).

`crates/app-server/Cargo.toml` depends on `codewhale-core` and `codewhale-tools`, not `codewhale-tui`. Its `Runtime::invoke_tool` (`crates/core/src/lib.rs` ~1321) drives the contract `codewhale_tools::ToolRegistry`, while the real registry and every tool implementation live in `tui/src/tools/`. The App control plane manages threads and state but cannot run a turn: the only `run_turn` is inside the TUI binary it does not depend on.

Pick one deliberately:
- (a) app-server becomes a pure client of the HTTP/SSE runtime API (`runtime_api.rs`) — engine stays one process, app-server orchestrates. Cheaper, preserves single authority.
- (b) the engine extraction (#6034 / #5316) lands and app-server links the real engine.

Doing neither leaves a permanent second-registry skeleton. Related: the shared-pet owner contract (#6109) also needs Engine metadata forwarded by app-server, which today only the TUI does.

Start with crates/app-server/Cargo.toml, crates/core/src/lib.rs around Runtime::invoke_tool, runtime_api.rs, and tui/src/tools/. Compare the HTTP/SSE client path with the engine-extraction work in #6034 and #5316; done means app-server can run a turn through one deliberate runtime authority and supports the Engine metadata needed by #6109.

Written by the indexing model from the issue text.