[Bug]: A long data root makes orcad serve with terminal survival silently off

**Operating system:** Linux (Synology DSM)
**Orca version:** built from `main` at `94e758666` — between v1.4.191 and v1.4.192

---

A data root long enough to push the terminal daemon's endpoint past
`sockaddr_un.sun_path` kills the daemon at startup. orcad's own listener name is
~5 bytes shorter, so in that band orcad comes up, reports ready, and serves
clients with terminal survival silently off. Every terminal then dies on the next
restart — the one thing forking a detached daemon exists to prevent.

Found on Synology DSM: a data root of 86 chars reproduced it, 84 was fine.

**Repro:**

1. Start orcad with a data root long enough that `/daemon/daemon-v.sock`
exceeds 108 bytes (104 on macOS) while the runtime's own socket does not.
2. Open a terminal — it works.
3. Restart orcad. The terminal is gone; `daemon.log` shows the daemon never bound.

**Why this warrants a startup refusal rather than a runtime check:** past the
limit there is no single failure to detect. A 109–110 byte path fails
`EADDRINUSE` against a name nothing holds; 111+ reports a *successful* `listen`
with no directory entry at all — which looks healthy to everything except the
dev+ino reads daemon endpoint ownership is built on.

Related: #10726 is the same kernel limit on the SSH relay's control socket —
different path, different failure mode.

Start at orcad startup and the code that builds the terminal daemon socket path; use the stated 108-byte Linux and 104-byte macOS limits, with daemon.log as the diagnostic. Done means a data root that would make the daemon endpoint invalid is refused before serving, while a valid root still permits terminal survival across restart.

Written by the indexing model from the issue text.