feat: tole-serve — server mode (HTTP + auth, Phase D3)

[ajianaz]

What problem does this solve?

tole runs only where its binary runs. The ecosystem already operates this way for uteke (uteke-serve on the macmini + uteke-mcp remote): memory became a shared service. tole's capabilities (durable sessions, jailed tools, memory loop) should be reachable the same way — from any device, without SSH-ing into the box, with sessions living server-side.

Proposed solution

tole-serve: a long-running daemon that hosts tole sessions server-side.

• Transport: MCP Streamable HTTP (so remote agents connect natively) + a thin REST surface for sessions/status (dashboard/monitoring).
• Auth: bearer token (uteke-serve model) to start; multi-user namespaces later if needed.
• Isolation: workspace jail per session (mechanism exists), jobs in their own process groups (exists), per-project uteke namespaces (repo-* convention).
• Durable sessions on the server: the JSONL log is the state — a client disconnect mid-turn parks the session resumably; any client can reconnect and continue.
• Builds on D1's MCP server core (same handler, different transport) and D2's async host bridging.

Acceptance criteria

• tole-serve starts with a token + workspace root; MCP clients connect over Streamable HTTP.
• Sessions are durable server-side; a killed client does not lose a running turn (resume semantics preserved).
• Auth enforced on every surface; Destructive tools never auto-allowed by server config.
• Docs: deployment runbook (macmini, mirroring the uteke-serve pattern).

Alternatives considered

• SSH + local CLI (current workaround) — works but no shared state, no multi-client, no editor integration.
• Exposing raw REST only — agents speak MCP natively; REST stays the thin monitoring layer.

Notes

• Tracks the approved D3 of the integration-surfaces plan (2026-09-18). Depends on D1 (MCP server core). Estimate: M–L.