docs: resolve OQ-TN-14 — unix in via local, stdio out (alktty owns process stdio)

Split the last open substrate-placement question:

- Unix: ships with the local feature v1 (dial_unix — same halves
  shape as TCP; the wire enum already carried unix per ADR-001;
  the params task's schema list includes all three values)
- Stdio: OUT of scope — a spawned process's stdin/stdout/stderr IS
  alktty's pipe mode (LocalTtyBackend + tokio::process + Stdio::piped,
  alktty tty-local.md): three multiplexed logical streams + the
  exit-code control chunk (alktty ADR-004) + signal forwarding
  (REQ-TTY-02). A stdio bridge here would be alktty's runner mode
  with the terminal stripped out — a strictly worse duplicate that
  also drops the semantics that matter (a byte tunnel has neither
  exit codes nor signals). Remote command execution composes via
  alktty on the same channels substrate.

Updated: open-questions.md OQ-TN-14 (resolved), overview.md feature
gate + deps + OQ summary, producer.md OQ ref, OQ-TN-10 promotion
(#3 split), phase-0-findings + both POC summaries' resolution notes,
params task (schema enum includes unix), local-socket-halves task
(unix ships, stdio does NOT — with the composition rationale),
oq-tn-14-tracker task repurposed (boundary-maintenance: re-opens only
if a consumer needs stdio-without-process-semantics — which would
need its own ADR, or if the alktty/alktunnels boundary needs
sharpening).

Verified: taskgraph valid (12 tasks, no cycles)

tasks/architecture/oq-tn-14-tracker.md

@@ -1,52 +1,60 @@
 ---
 id: architecture/oq-tn-14-tracker
-name: "[external-trigger, deferred-oq] OQ-TN-14 unix/stdio placement tracker"
+name: "OQ-TN-14 follow-through: unix lands with local v1; stdio stays alktty's"
 status: pending
 depends_on: []
 scope: single
 risk: trivial
 impact: isolated
 level: research
-tags: [architecture, deferred-oq, external-trigger, unix, stdio]
+tags: [architecture, external-trigger, unix, stdio, alktty]
 ---
 
 ## Description
 
-External-trigger tracker for OQ-TN-14 (`docs/architecture/open-questions.md`
-— unix-socket and stdio substrate placement, currently `open` leaning
-unix-yes-v1). This task is NOT actionable implementation work; it tracks
-whether the unblocking condition has arrived. If the condition arrives, this
-task flips the OQ (and the implementation task `tunnels/local-unix-halves`
-below) from its deferred/open posture to actionable.
+OQ-TN-14 is resolved (open-questions.md, 2026-09-07): unix ships with
+the `local` feature v1 (`tunnels/local-socket-halves`); stdio is OUT of
+scope — a spawned process's stdio is alktty's pipe mode (exit codes +
+signals are tty semantics, not tunnel semantics); remote command
+execution composes via alktty.
 
-Unblocking conditions (any one):
+This task stays open as the boundary-maintenance tracker (research
+level — not implementation work). It re-opens the question only if a
+concrete consumer demonstrates the resolved posture is wrong:
 
-1. A consumer needs unix-socket tunneling through alktunnels (a hub exposing
-   a docker container's unix socket, or a local daemon bridge).
-2. The `tunnels/crate-init` task lands and the `local` feature module needs
-   its v1 surface finalized (the decision point baked into that task).
+1. A consumer needs stdio tunneling with NO process semantics (no exit
+   code, no signals) — e.g. piping an already-running long-lived
+   process's existing stdio. That is a different resource shape (the
+   pipe IS the resource, no dial); it would need its own ADR, not a
+   silent addition to `local`.
+2. A consumer reports confusion about when to use alktunnels vs alktty
+   for a stdio-like flow — the composition boundary in OQ-TN-14 needs
+   sharpening in the docs, not code.
 
-If neither arrives by the end of the v1 implementation phase, the OQ stays
-open and `local` ships TCP+UDP only (the lean posture ADR-004 endorses).
+If neither arrives, this task closes with the implementation phase.
 
 ## Work
 
-- Re-read OQ-TN-14 + `docs/architecture/overview.md` §Feature Gates when
-  triaging; confirm whether the unix helper ships with `local` v1.
+- Re-read OQ-TN-14 + alktty's `tty-local.md` §pipe mode at triage;
+  confirm the boundary held (no stdio-shaped resource got registered
+  as a tunnel resource).
 
 ## Verification
 
-- [ ] Tracked (this file existing and being reviewed at triage time IS the
-      tracking mechanism — no code or doc change is expected until the
-      condition arrives)
+- [ ] Tracked (this file existing and being reviewed at triage time IS
+      the tracking mechanism — no code or doc change is expected unless
+      a boundary condition above arrives)
 
 ## Out of scope
 
-- Implementing the unix/stdio helpers (see `tunnels/local-unix-halves`)
+- Implementing stdio bridging (would need its own ADR per the
+  conditions above)
 
 ## References
 
-- docs/architecture/open-questions.md OQ-TN-14
+- docs/architecture/open-questions.md OQ-TN-14 (the resolution)
+- alktty `docs/architecture/tty-local.md` §pipe mode (the owner of
+  process stdio)
 - docs/sdd_process.md §Deferred OQs and the blocker-task half
 
 ## Notes