feat(orcad): run the terminal daemon, and the ops contract around it

[nwparker]

	Files	Added	Deleted	Net
Test	19	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​925	$\color{#cf222e}{\Huge{\mathbf{−}}}$​24	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​901
Prod	20	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1305	$\color{#cf222e}{\Huge{\mathbf{−}}}$​104	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​1201

Plan items 3 and 4, stacked on #16374. The design says these must be co-designed, not sequential — the instance lock, supervision contract and health check are all wrong if written with one process in scope.

Item 4: work now survives an orcad restart

orcad previously declared canRecoverPersistentLocalPtys: () => false. But ssh-execution-boundary.md:77 recommends the peer model because "daemon-backed PTYs stay live across a normal runtime restart so the runtime can reattach". So orcad was shipping the peer model minus the property it is recommended for — every restart, update and rollback destroyed all running work.

The flag is now a function of real state, daemonOwnsFreshPersistentPtys(), rather than a hardcoded answer in either direction.

stopOrcadDaemon calls disconnectDaemon, never shutdownDaemon — shutdown kills the daemon and every PTY under it, which would make orcad's own restart destructive.

Verified end to end, not just unit-tested. With a live PTY, stopping orcad leaves the daemon running:

daemon pid=73596
terminal=term_86a2f71e-829a-45b9-af7b-59f9df8f2fa0
daemon alive after orcad stop, WITH a live PTY: YES

With no PTYs it exits promptly — correct idle behaviour, nothing to preserve. I checked that case first and briefly mistook it for a defect; testing the real scenario is what settled it.

Item 3: the ops contract

• Bind policy. Was hardcoded exposeNetworkByDefault: true → 0.0.0.0. Now loopback by default, verified live:

  [orcad] orcad is bound to 127.0.0.1 (local only). Reach it from another machine with
  an SSH local port-forward, or re-launch with --bind to expose it.
  

  That matches the design's deploy model, and it is the inverse of what shipped.
• Instance lock on the data root before profile load.
• Supervision covering both relationships — who supervises orcad, and orcad supervising the daemon.
• Health spanning both processes. Readiness now carries a real PTY-spawn self-test, so a green orcad with a dead daemon is not reportable as healthy:

  "terminalDaemon":{"state":"live","ownsFreshSessions":true,"pid":54172,
    "protocolVersion":36,"selfTest":{"ok":true,"coverage":"pty-spawn","verdict":"healthy","durationMs":8}}

It also closed a hole in item 0's gate

My smoke-load gate asserted on the text of an argv rejection — but that string is a literal in the bundle, so a crash printing it would falsely match, and the assertion could pass against a bundle that never loaded. It now uses an explicit --orcad-smoke-load-check flag that exits 0 before probing natives or binding a port, and asserts status === 0. Strictly better than what I wrote.

Proof

1,614 tests pass across src/main/orcad + src/main/runtime/rpc. Ratchet 0; build-orcad green (4.73 MB, zero electron and node:sqlite); smoke:orcad-terminal passes; typecheck and lint clean.

Full suite: the only failures are 4 tests that fail identically on main — verified by running the same set on both and diffing the failure names, which came out empty. This branch touches none of those files.

Trade-offs

One deliberate, and it is a security improvement: orcad now binds loopback instead of every interface. Anyone relying on the old wide bind must pass --bind explicitly. That is the inverse default from what shipped, chosen because an unattended server should not publish an authenticated endpoint on every interface without someone asking for it.

[OrcaWin]

Closing as superseded: the daemon and ops contract from this PR landed as part of #16398, and orcad has since become the managed server every SSH host runs (#24863).