:bug: Cortex being down can break harness

Description

abctl service install writes proxy settings into the user's environment so any harness it was pointed at and routes through Cortex on :47600. When Cortex is down for any reason (abctl service stop, launchd killed it, abctl service uninstall didn't fully clean up), the routing stays configured but the port isn't listening. The harness's next request hits connection-refused. Cortex being down should mean "no observation," not "no traffic."

The failure mode is invisible to a user who has forgotten Cortex exists:

• The error surfaced is generic ("network error", "cannot reach API"), not "your local proxy is down."
• Nothing tells them their traffic is being routed through localhost.
• Remediation (abctl service start or unsetting the routing) requires knowing Cortex exists.
• Not scoped to a specific harness — anything abctl service install configured is affected.

Reproduction

1. Install Cortex on a laptop where Claude Code was working, then abctl service install.
2. Confirm Claude Code still works.
3. abctl service stop.
4. Send a message in Claude Code → connection error.

Potential approaches

A. Add a lightweight shim on :47600, move Cortex to :47602.
Shim always listens; forwards to Cortex when up, direct to origin when down. Harness never sees a dead port. Preserves abctl service stop as a real "kill the process" verb.

Cost: a second persistent service, one more proxy hop on every request, and more code between harness and origin — CONNECT, HTTP/2, WebSocket upgrade all get one more layer.

B. Make Cortex itself soft-fail; rename its lifecycle verbs.
Cortex process stays up as a transparent passthrough whenever its observation pipeline is down or "stopped." abctl service stop becomes "pause observation," not "kill the transport." abctl service uninstall is the only verb that removes the process and unroutes the harness. No new process, no new hop; coupling is removed by design.

Cost: a UX contract change on stop — it no longer stops the process, and existing operators have to adjust

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com

Start by tracing the abctl service install, stop, and uninstall behavior, including how routing through :47600 is configured. Compare the shim and soft-fail approaches in the issue before choosing a lifecycle contract. Done means a stopped Cortex does not cause harness traffic to fail, with the resulting service semantics clear for users.