fix(tui): Linux follow-ups for the Rust agent runtime removal (plan r8, run on WSL2) - #9

`zypi -p` runs the Python agent as a plain child on the user's terminal. The TUI's agent
learns that its client is gone from EOF on its stdin; here stdin is the terminal, so that
signal does not exist. Killing only zypi (kill -9, kill <pid>, an IDE's stop button) left the
agent and the tools it was running going on the terminal: a `sleep 300` started by the agent
was still there afterwards.

- zypi names itself to the agent in PI_AGENT_PARENT_PID (print_mode::agent_command).
- pi_agent_cli removes the variable first thing in main(), so nothing it starts inherits it.
  It is used only if the pid is this process's parent, or a process that no longer exists
  (the parent died while the agent was starting). A live process that is not the parent is a
  wrapper script in between: the watch stays off. POSIX only.
- In -p mode a task polls os.getppid() every 0.5 s; once the parent is not the one named it
  asks for the same stop as SIGTERM. The turn is cancelled and the process group of every
  running tool is reaped. -p now also stops on SIGTERM and SIGHUP, with exit status
  128 + the signal number.
- _StopRequest is the piece both paths share; serve() (the stdio agent) behaves as before.

An environment variable rather than a flag, so a zypi and a pi_agent_cli of different versions
still work together. Not PR_SET_PDEATHSIG: it is Linux-only, tied to the thread that started
the child, and after a SIGKILL it would leave the tools orphaned.

Limits: a PI_AGENT_COMMAND that points at a wrapper script keeps the watch off, so killing
only zypi still leaves that agent behind. Windows has no counterpart.

Tests: 15 pytest cases in packages/pi-agent-cli/tests/test_print_shutdown.py (POSIX only;
disabling the watch makes the two that depend on it fail) and one Rust test in pi-pager-bin.
Against a built zypi (scripts/tui_pty/print_exit.py, added later in this series), SIGTERM,
SIGKILL, SIGHUP and SIGINT sent to zypi alone leave nothing running.

With --sandbox on Linux zypi re-executes itself under bubblewrap. A plain bwrap only waits for
its child, so killing bwrap alone (kill $!, timeout, an IDE's stop button, a supervisor that
signals just the process it started) left zypi, the Python agent and the agent's running tools
on the terminal. Measured with bwrap 0.9.0 on WSL2: SIGKILL, SIGTERM and SIGHUP sent to bwrap
all left them alive.

bwrap now gets --die-with-parent: the sandboxed child is SIGKILLed when bwrap dies (and bwrap
itself when its parent dies). The agent then sees EOF on its stdin and reaps its tools on the
way out; all of them are gone within a second. It is a bwrap option, so it goes before `--`;
a test pins the position.

Trade-off: the child dies by SIGKILL, so when only the outer bwrap is signalled with SIGTERM or
SIGHUP zypi cannot restore the terminal (alternate screen, raw mode). Before, the whole tree
stayed up instead. Easy to take back: this commit is the flag and its test.

SandboxManager::apply() degrades on purpose: where the platform cannot enforce the profile (on
Linux, a kernel without Landlock) or applying it fails, it logs, returns Ok and the run goes
on with none of the profile's file or network limits. The user was never told: the status bar
label is drawn from profile_name(), which is None both for "no sandbox asked for" and for "a
sandbox that did not take".

- pi-sandbox keeps the reason (SandboxManager::not_enforced; pi_sandbox::not_enforced once
  installed) and builds the texts: not_enforced_warning (the profile, the reason, what is
  lost) and not_enforced_label (`sandbox:workspace (not enforced)`). A build without the
  `enforce` feature reports it as well.
- pi-shell's apply_sandbox prints the warning on stderr at start-up.
- The welcome top bar and the session status bar draw the label in the error colour where the
  label of an applied profile goes. The stderr line is behind the alternate screen by then.

Checked under a pseudo-terminal on WSL2 (kernel 5.10, no Landlock): the warning and the label
appear. Not exercised: a kernel with Landlock, where the profile is applied and no label may
show. Only unit tests cover that side, because apply() would confine the test process for
good.

Tests: 5 new in pi-sandbox (87 in the crate together with the previous commit).

The TUI's agent child inherited zypi's stderr, which app::run points at /dev/null once the
TUI is up, so a Python traceback or warning from the agent went nowhere.

The child's stderr is now <home>/logs/agent.stderr.log:
- appended to across runs, with one `--- agent started <rfc3339> (zypi pid N) ---` line per
  spawn so that a run's output can be told apart;
- owner-only (0600) on Unix, since a traceback can quote prompts, paths and keys;
- rotated at spawn: past 1 MiB it becomes agent.stderr.log.1 (replacing the one before) and a
  new file starts. The size is not enforced while an agent runs;
- when it cannot be opened (the `logs` path is a file, a read-only home) the agent still
  starts and its stderr is discarded as before, with a tracing warning.

`-p` is not affected: there the agent keeps the user's terminal as its stderr.

Tests: 6 in acp::spawn::agent_stderr_tests (location, start marker, append, rotation at the
limit, file mode, a log that cannot be opened).

Neither change touches production code.

- pi-pager, tool_media_same_length_same_mtime_rewrite_retries_failed_load: the stamp that
  tells a rewrite from an untouched file includes ctime, which comes from the kernel's coarse
  clock. At CONFIG_HZ=100 (WSL2's 5.10 kernel) a tick is 10 ms, and a rewrite in the same tick
  as the first stamp carries the same ctime and looks unchanged. The test now lets 25 ms pass
  between the two writes; a real slow write is never that fast.
- pi-pager-minimal, committed_edit_keeps_diff_line_backgrounds: Theme::current() follows a
  process-wide switch that the terminal-native tests turn on while they hold
  theme_cache::test_lock(). This test did not take the lock, so with the default thread count
  it could run in that window, get the native palette and find no diff backgrounds. It takes
  the lock now. 40 runs each with the default threads, --test-threads=1, the test alone, and
  (default threads and the test alone) with every CPU busy: no failure.

…fest

scripts/tui_baseline.toml is the manifest that scripts/tui_baseline.py, and with it the TUI CI
job, runs. Two suites join it and doctor_cmd:: is no longer skipped:

- pi-pager: drop skip = ["doctor_cmd::"]. It was there because the voice probe queried the
  audio input device, which hangs on macOS CoreAudio without microphone access. The probe is
  gone (plan section 10.10) and the 12 tests pass without an audio device. reference_passed
  5552 -> 5577: the 5,559 of the last CI run, plus those 12, plus the 6 agent_stderr tests.
- New suite pi-pager-render (--lib; 1,092 passed, 2 ignored on Linux). One test is listed in
  known_failures: tmux_probe::tests::successful_near_deadline_exit_still_returns_captured_output
  spends 1.2 s of a 1.5 s budget in a shell script, so it fails when the machine stalls. It
  failed twice on WSL2, both times on the first run after the binary was linked, and not once
  in the 94 runs after that, idle or with every core busy. known_failures only reports: the
  test is named in the report when it fails, and the run is not blocked.
- New suite pi-pager-minimal (--lib; 79 passed).
- pi-pager-bin: 20 -> 21, for the test that names zypi as the agent's parent in `-p` mode.

The numbers are WSL2's, not the runner's. The first CI run with the unskipped doctor_cmd tests
and the two new suites decides whether they hold there; if doctor_cmd does not, put the skip
back.

Whole manifest on WSL2 (python scripts/tui_baseline.py test): exit 0, 10 suites, 8,633 passed,
1 known failure, 22 ignored, 1,469 s.

…l terminal

scripts/tui_pty/ runs a built zypi under a pty (a pyte screen reads what it draws) and looks
at the process tree it leaves. They are the Linux counterpart of the macOS PTY runs in the
plan (sections 10.7 and 10.10). They need a built binary, so they are not part of pytest or CI.

- smoke.py: welcome page, one turn, /model, /exit, a restart in the same home with /resume,
  the agent's stderr log, and with --sandbox PROFILE what the status bar says about the
  profile. 23 checks on WSL2 (26 with --sandbox workspace).
- exit_matrix.py: while the agent runs a long bash tool call, leave zypi six ways (/exit twice,
  kill -9, SIGTERM, SIGHUP, closing the terminal, Ctrl-C) from two launch styles; nothing may
  be left running. 12/12 on WSL2 (14/14 with --sandbox workspace).
- print_exit.py: `zypi -p` while only zypi gets SIGTERM, SIGKILL, SIGHUP or SIGINT; the agent
  and its tool call must stop too. 4/4 (the tool survived before the -p fix).
- pty_term.py (the driver and the /proc helpers) and zypi_env.py (finds the binary, builds a
  throw-away PI_HOME, HOME and working directory and an environment from scratch, so what the
  caller's shell exports, PI_HOME included, never reaches zypi and a real ~/.pi-python is not
  touched).

scripts/tests/test_tui_pty.py covers the helpers: 10 tests on Linux; on Windows 5 pass and 5
are skipped.

The plan's macOS side is merged (#6 to #8); this is the Linux counterpart, run in WSL2
(Ubuntu 24.04, kernel 5.10 without Landlock, bubblewrap 0.9.0).

- docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md: section 10.10 (what was run on Linux, the
  findings and what was done about each, what is not verified, what is left for the user to
  decide), the r8 revision-log line and the validation tables.
- docs/baselines/tui.md: 10 suites, the numbers measured on WSL2 (not yet confirmed by CI), the
  tmux known failure, and a section on the PTY drivers.
- CHANGELOG.md, [Unreleased]: the agent's stderr log, the not-enforced notice, the `-p` orphan
  fix, --die-with-parent and its trade-off.
- AGENTS.md: how the Rust tests and the PTY drivers are run.
  packages/pi-agent-cli/AGENTS.md: the agent's stderr and the `-p` parent watch.
  docs/TUI-AND-CODE-AGENT.md: where the stderr log is and what --sandbox says when it is not
  in force.

Verification of the whole series: scripts/tui_baseline.py test exits 0 (10 suites, 8,633
passed / 1 known failure / 22 ignored); pytest 2,160 passed / 30 skipped on Linux (WSL) and
2,156 passed / 34 skipped on Windows; ruff check and ruff format --check clean. The numbers of
the new suites and of the unskipped doctor_cmd tests are WSL2's; the first TUI CI run on the
pull request confirms or corrects them.

… microphone

fake_standalone_facts_compose_through_shared_view asserts issue_count() == 1, but
collect_report_with also runs apply_voice_probe, which on Linux looks for pw-record,
parec or arecord on PATH. A host without one, as the CI runner is, gets a
voice.no-input-device issue on top: 2 instead of 1. The first TUI CI run of PR #9
failed on exactly that; WSL2 has all three recorders, which is why it passed there.

The test now leaves that finding out of the count (it checks the facts it composes,
not the machine it runs on). Verified by running the test binary directly with
PATH=/nonexistent: before the change 11 passed and 1 failed with left: 2, right: 1;
after it 12/12, and 12/12 with the recorders on PATH as well.

The docs said doctor_cmd:: needs no audio device and that r5 had removed
apply_voice_probe. Neither is true (the function is still there and is called on
every report), so the manifest comment, the baselines page and plan section 10.10
are corrected and now carry the numbers of that CI run: 8,633 passed, every suite
equal to the WSL2 count except this one test.