fix(server): default the runtime home to ~/.pylon-code everywhere

[rynfar]

Problem

The desktop app has kept Pylon's state under ~/.pylon-code since the fork, but two other launch paths still defaulted to ~/.t3: the t3 CLI (resolveBaseDir in apps/server/src/os-jank.ts) when neither --base-dir nor T3CODE_HOME is set, and the desktop's SSH remote launcher, which hard-coded --base-dir "$HOME/.t3" for the server it starts and kept its own state under ~/.t3/ssh-launch. AGENTS.md names ~/.t3/userdata as T3 Code's database — with incompatible migration numbering — and forbids opening it from a Pylon server, so a bare npx t3 on a machine that also runs T3 Code did exactly the forbidden thing. PR #187's user doc was the first to depend on the default and had to hedge around it.

Fix

Every place a Pylon server or its data is opened by default now uses ~/.pylon-code. T3CODE_HOME and --base-dir are unchanged (compatibility identifiers). There is deliberately no fallback to ~/.t3, because it may be T3's data.

• CLI. resolveBaseDir defaults to ~/.pylon-code. When the default is used, <default>/userdata is absent, and ~/.t3/userdata exists, the server writes one hint line to stderr telling the user to pass --base-dir ~/.t3 (or T3CODE_HOME) or move ~/.t3/userdata into ~/.pylon-code/userdata, which brings settings and secrets with it. It never fires when a base dir was given, including the desktop's bootstrap, and never for worktree dev runs. Review caught that the first version went through the Effect logger to stdout ahead of --json output; it now bypasses the logger and a test captures the JSON stream to prove it stays clean.
• SSH launcher. Remote servers start under $HOME/.pylon-code with state in $HOME/.pylon-code/ssh-launch/…. On first launch after the upgrade, a best-effort legacy block finds the old ~/.t3/ssh-launch/<key> state, stops the old launcher-managed server only if ps confirms the recorded pid is a serve --host 127.0.0.1 … --base-dir $HOME/.t3 process (a reused pid is spared), renames the old state dir to .migrated, and prints the same hint to stderr. Every line in the block ends in || true, and the test walks the generated scripts requiring that; sh -n passes on all five scripts.
• Maintainer scripts. migrate-dev-db.ts seeds from ~/.pylon-code/userdata/state.sqlite and refuses to rebuild either ~/.t3 or ~/.pylon-code (review caught that moving the shared-home constant had dropped the ~/.t3 refusal — the guard is now a separate list and runs before the source-exists check). t3-sqlite-state.ts refuses exec against both homes, canonical-path compared.
• Docs. remote-access.md, keybindings.md, environment-theme.md, observability.md, internals/scripts.md, the test-pylon-app skill, and AGENTS.md's runtime-home glossary line. install.md gains a WSL paragraph: the in-distro backend takes the new default too, and because ~/.pylon-code/wsl-runtime already exists there, the migration is mv ~/.t3/userdata ~/.pylon-code/userdata, guarded on the destination being absent. That command was run against three sandboxes (migration, populated destination refused, nothing to move).

What happens to existing installs

• Desktop: nothing changes.
• CLI-started servers and SSH remotes: start empty under ~/.pylon-code and print the hint; old data stays in ~/.t3 until moved. On a remote host whose ps cannot report process arguments, the old server is left running (safe direction) while its state dir is retired; stop it by hand.
• WSL backend: same as CLI, per the new install.md paragraph.

Verification

• 18 files / 215 tests on the focused set (os-jank, ssh tunnel, all cli/, bin, dev-runner, both maintainer scripts); t3, @t3tools/ssh, and @t3tools/scripts typechecks clean; lint, format, git diff --check clean.
• Six mutation checks across three review rounds: reverting the DEFAULT_SERVER_HOME fails the SSH assertion; restoring the single-home guard fails the refusal test; reverting the guard hoist fails the ordering test; the --json test fails on the pre-fix logger route.
• Legacy SSH block exercised in a sandbox with a real pid: matching stale server stopped, unrelated sleep holding the pid spared, directory retired, idempotent on re-run, exit 0 on a clean host.
• Three independent review passes (full review, two scoped re-reviews).
• Not verified: a real SSH host, a real WSL distro, and a live desktop session.

Follow-up once #180 lands: append the durable-facts record for this decision (drafted in the review report, not committed here because the file only exists on that branch).

---

Claude Fable 5 in Pylon.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[github-actions]

Thread transfer impact

✅ Thread transfer remains within every enforced ceiling.

Provider	Metric	Main baseline	This PR	Impact	PR ceiling
Codex	Total thread wire	13.7 KiB	13.6 KiB	−178 B (−1.3%)	15.1 KiB	✅
Codex	Thread snapshot wire	6.9 KiB	6.9 KiB	+4 B (+0.1%)	7.3 KiB	✅
Codex	Live turn WebSocket wire	6.8 KiB	6.6 KiB	−182 B (−2.6%)	7.8 KiB	✅
Codex	Live turn WebSocket decoded	58.7 KiB	57.2 KiB	−1.5 KiB (−2.5%)	66.4 KiB	✅
Codex	Live turn messages	11	10	−1 (−9.1%)	21	✅
Claude	Total thread wire	13.5 KiB	13.6 KiB	+41 B (+0.3%)	15.1 KiB	✅
Claude	Thread snapshot wire	6.9 KiB	6.9 KiB	−1 B (−0.0%)	7.3 KiB	✅
Claude	Live turn WebSocket wire	6.6 KiB	6.6 KiB	+42 B (+0.6%)	7.8 KiB	✅
Claude	Live turn WebSocket decoded	58.0 KiB	58.1 KiB	+44 B (+0.1%)	66.4 KiB	✅
Claude	Live turn messages	9	10	+1 (+11.1%)	21	✅

Baseline: 721713e · PR result: 66401f0 · Source CI: success

Scenario and decoded snapshot size

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 109.5 KiB
• Claude decoded thread snapshot: 110.2 KiB

Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.