fix(tmux-restore): trigger on the tmux socket appearing, not a 45s timer

[ZacxDev]

Trigger the boot restore unit on the tmux socket appearing, instead of a fixed OnActiveSec=45s timer.

This is the half that makes cold-boot restore actually work. #1351 (squash 9353d958)
stopped the unit from manufacturing a tmux server that systemd immediately killed — but
after it, a cold boot refuses and the operator re-runs by hand. This makes the unit fire
when there is a server to restore into.

The change

• systemd.user.paths.tmux-session-restore with PathChanged=%t/tmux-%U/default,
  WantedBy=default.target; the OnActiveSec=45s timer is gone.
• The service is gated by ConditionPathExists= on the same socket path.
• TMUX_TMPDIR=%t pinned on the service (its two siblings already pin it; this unit did
  not, and worked only because the user-manager environment happened to carry it).
• No RemainAfterExit.
• graphical-session.target ordering dropped — it never ordered against anything tmux-related.

Twelve controlled systemd experiments, each with positive AND negative controls

The design is measured, not reasoned. The load-bearing results:

• 🔴 PathExists= BUSY-LOOPS. Measured: 5 runs in 8 seconds, both units reaching
  start-limit-hit. Under this unit's OnFailure=notify-failure@%n — which bypasses DND —
  that is an alarm on every boot, forever. This is the obvious implementation and it is
  wrong.
• PathChanged= fires exactly once, no loop — but it also fires on socket
  DELETION, not only creation. That second fact is what keeps the exit-0 decision below
  honest.
• A failing ConditionPathExists fires OnFailure ZERO times, against a positive
  control that fires once. So the condition genuinely suppresses the failure path rather
  than merely appearing to.

Why not RemainAfterExit=yes

It is measured to work, and it is not needed here. RemainAfterExit would only be
required under PathExists= — so choosing the event-type watch removes the need rather
than trading one hazard for another. Keeping it would be strictly worse: with
KillMode=control-group, the unit would then own the operator's tmux server, and
systemctl --user stop would take the whole workspace with it.

The exit-0 refusal: KEPT, but its reason is REPLACED

#1351's refusal returns 0 deliberately, and its stated justification was "no-server is the
standing cold-boot state because the unit fires on a 45s timer". This change removes that
precondition, so leaving the comment would have shipped a claim the code contradicts.

Re-derived, the answer still holds, for a different reason: the path unit re-fires on server
shutdown, so "no server" moves from every boot to every shutdown rather than
becoming rare; ConditionPathExists absorbs the ordinary case; and what actually reaches
the refusal is a race, which must not raise a DND-bypassing alarm. The comment, the test
docstring and the test's assertion message were all rewritten together, so the justification
cannot rot out of step with the code.

Verification

Tests: new scripts/tests/test_tmux_restore_trigger.py (structural, via a new
scripts/testlib/nix_units.py) plus test_nix_units.py for the helper — 57 tests.
Red-at-base / green-at-HEAD confirmed, with the base tree carrying the test files so nothing
goes red merely for a missing import.

Mutation: 18/18 killed, each by its own guard's own assertion text, both controls green,
zero survivors, zero no-op edits, zero killed-by-a-neighbour. Run under
PYTHONDONTWRITEBYTECODE=1. Covers: re-adding the timer · deleting the path unit ·
PathChanged→PathExists · triggering a different service · dropping WantedBy ·
dropping TMUX_TMPDIR · TMUX_TMPDIR=/tmp (the seam mutant) · dropping
ConditionPathExists · guarding a different path than is watched · hardcoding the uid ·
watching the directory not the socket · adding RemainAfterExit · three on the advice text
in tmux-restore-observe.sh · three on nix_units.section().
One mutant survived on the first pass and produced a real fix to a prose guard.

Gate — all three tier/tree combinations green on 4fbe8440 (contains origin/main
e9e9075f):

tier	verdict
dev host gate.sh --tier both	PASS — pytest 22056 passed / 0 failed; node 1449 / 0 fail
nix sandbox checks.pytests	PASS — 22059 collected / 22056 passed / 0 failed
nix sandbox checks.nodetests	PASS — 5 suites / 41 files / 1449 tests / 0 fail

The two nix derivations were built one at a time (a combined invocation causes store
contention and false failures), from a git archive extract rather than the worktree
directly (a worktree's .git is a FILE and defeats the sandbox's git-config isolation,
failing exit=2 before any test runs), and every verdict was read from nix log — a
nix build prints no test output and a derivation that ran zero tests exits 0 identically.

Blast radius

Reversible — one commit revert restores the timer. It changes WHEN the unit runs, not
what it does. Worth knowing: this only takes effect after a home-manager switch, and the
behaviour it fixes is only observable across a real reboot, which is the one thing that has
overturned two successive hypotheses in this arc.