feat: phase 1 contract work that needs no decision, and the phase 0 gates (plan r9) - #10

`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.

…al stdio (plan 1.P7)

The stdio contract suite could not reach the tool side of the protocol: its mock LLM never calls a
tool, so a permission request, or a cancel with something running, never happened on the wire.
tests/test_acp_stdio_tools.py drives tests/_tool_agent.py (the real serve() with a scripted LLM
turn that calls one tool) the way the TUI drives the agent, and asserts what the pager depends on:

- in ask mode a `write` call is announced as a tool_call update and then put as
  session/request_permission, before the tool runs: title, kind, raw_input and the two options
  allow-once / reject-once (the tool had not run when the request arrived);
- allow-once runs the tool; reject-once and a `cancelled` outcome do not, and the turn still ends
  (the model is told); auto mode never asks;
- session/cancel ends the prompt as `cancelled` while a question is open (the pager answers it
  `cancelled` after the cancel) and while a `bash` call runs, which is then reaped (POSIX only);
  with nothing running, or for a session the agent does not have, it is harmless.

_tool_agent.py gains PI_TEST_TOOL_CALL (a JSON tool call replacing the long bash) and
PI_TEST_PERMISSION (default auto, as before). Its stream now ends `aborted` when the signal is set
before the next LLM call, as the LangChain adapter does; without that a cancelled turn went on to
the next scripted call and ended end_turn, which says something about the stream, not the agent.

8 tests (7 on Windows, where the bash one is skipped), plus the 4 shutdown tests that share the
helper, all pass on Windows and in WSL2. Mutation checks: an agent that allows whatever the client
answers fails the two refusal cases; one that never asks fails 5; one whose cancel does nothing
fails the two cancel cases (by timeout).

`read_text_lines(path, max_lines=1)` read and decoded the whole file and then cut the first line
off, so listing sessions cost the total size of every session file (one of the files on this
machine is 1.85 MB). It now reads only as far as the lines asked for, with the same newline
handling as before (universal newlines, then `str.splitlines`), so every result is the same;
the tests compare against the old behaviour over awkward line endings and check that bytes
after the header are never decoded.

`LocalExecutionEnv.list_dir` called `file_info` on every child: a worker-thread round trip and
about six `stat` / `realpath` calls each, 1.3 s for a directory of 1000 files on Windows. It
is now one `scandir` in one worker thread and one `resolve` for the directory, with the same
`FileInfo` for every child (a test compares them child by child, symlinks included). A child
that disappears while the directory is read is left out instead of failing the whole listing.

Both were found by measuring `session/list` for plan 0.7 (scripts/session_list_bench.py).

`JsonlSessionRepo.list` reads the header of every session file, so a listing, and every
`session/load`, which looked its session up through it, cost the whole directory.

`list_page({limit, after, cwd})` walks the file names newest first (the names start with the
creation time) and reads a header only when the page reaches that file; it stops once the page
is full and the next session is in sight, and says where the next page starts (`next_after`,
a file name, so no state is kept and a cursor survives a restart). A page that carries a
cursor is never followed by an empty one.

`find(id)` picks the candidates from the file names (`...-<id>.jsonl`) and reads only those
headers; only when none of them is the session does it fall back to reading every file, as
`list` would, so a file named by someone else is still found.

`list` itself is unchanged.

…eal agent

scripts/session_list_bench.py writes a synthetic PI_HOME (N sessions, a third of them the
project's) and times, over stdio as the TUI talks to the agent: start up to `initialize`, the
first page of `session/list`, every page, the cross-project listing, `session/load`, and the
repo and preview parts in-process. It is how plan 0.7 gets the number ADR1 hangs on (what a
list costs once the TUI no longer reads the session files itself).

…lan 1.P1)

The picker asked for `session/list` once and ignored `nextCursor`, which was fine while the
Python agent answered with everything but would show only the first page once it pages. It now
follows the cursor until the agent sends none.

The cursor is opaque (ACP): it is handed back exactly as received and never read. The loop also
ends on an empty cursor, on a cursor the agent already gave (it would go round forever), and at
100 pages (5000 sessions at the agent's 50 a page); the sessions collected so far are shown and
a warning is logged. An error on any page fails the whole fill with the same `seq`, so a picker
never silently stops half way.

Tests drive a scripted agent over the same channel the real one uses: several pages in order
(with the cursor and cwd checked on every request), a single page, a repeated cursor, an empty
cursor, the page cap, and an error on a later page. Two mutations (the cursor not sent back; no
repeat check) make exactly the two tests that cover them fail.

…up by id (plan 1.P1)

`session/list` answered with every session and ignored `cursor`. It now returns
SESSION_LIST_PAGE_SIZE (50) sessions, newest first, with `nextCursor` while more follow. The
cursor carries the file name the next page continues below, so the agent keeps nothing between
requests; a string it did not issue is `invalid_params`. The TUI follows `nextCursor` (previous
commit), so its picker still shows everything.

`load` / `resume` / `pi/session/delete` found their session by listing all of them; they now
ask the repo for that id (one header read).

Measured on a synthetic home with the real agent (scripts/session_list_bench.py, medians):
Windows, 1000 sessions: first `session/list` 3171 ms -> 113 ms, `session/load` 2084 ms -> 108 ms;
WSL2 ext4, 1000 sessions: 492 ms -> 79 ms and 560 ms -> 78 ms. See plan section 10.11.

ACP lets a client hand an agent MCP servers in session/new, session/load and session/resume,
and says an agent MUST support stdio ones. The Python agent connects to none (MCP is a Phase 4
non-goal) and used to drop the list without a word, so a user who had set a server up in their
editor just found its tools missing.

The three handlers now pass the list to the deferred session setup, which logs a warning and
sends one agent message once the response has flushed, like the other setup notices:

  This agent does not connect to MCP servers, so the 2 MCP servers the client passed (a, b)
  were ignored and their tools are not available in this session.

Only the names are used, in the log and in the message (at most 8, each cut at 60 characters,
then "and N more"): `env`, `headers`, `args` and `url` routinely hold tokens. Servers given as
dicts or as the SDK's models are both read; one without a usable name shows as "(unnamed)".

The departure from ACP stays a documented deviation, not a fix: packages/pi-agent-cli/AGENTS.md
gets a section saying what the agent does with the list, why the notice is the place to start
if MCP is ever implemented, and that `initialize` advertises no mcpCapabilities.

tests/test_mcp_notice.py (12): the names and the message for none / one / many / long lists,
no token in the message or in the log, and the agent's own new_session, load_session and
resume_session driven with a recording client (one notice each; none for an empty list; the
session still answers a prompt). Mutation: load_session without the list makes
test_load_and_resume_say_it_too fail.

…1.P4)

The pager read `.mcp.json`, `~/.claude.json` and Cursor's `mcp.json` (pi_shell
`load_mcp_servers`) and put every server it found into the request, including each one's `env`
and `headers`. The Python agent connects to none of them, so that only copied tokens into a
process that threw them away, and the user was told nothing.

Both requests now carry an empty list, and the `session.create.done` log no longer reports a
server count. `load_mcp_servers` is left in pi-shell; nothing in the pager calls it any more.

The test writes a project `.mcp.json` with a token in it, checks that `load_mcp_servers` still
finds it (so the test cannot pass because the file was never read), and drives NewSession and
LoadSession through a scripted agent: neither request has an `mcp_servers` entry. Mutation:
putting `.mcp_servers(load_mcp_servers(..))` back into both calls makes the test fail (WSL).

…rrive in pages

docs/TUI-AND-CODE-AGENT.md still drew MCP in the TUI's box and said nothing about two things
the ACP side now does differently: the agent ignores the MCP servers a client passes (and says
so in the session), and `session/list` returns 50 sessions at a time with `nextCursor`, which
zypi follows.

… failed

The stdio bridge waited only for the pager's own stop request. An agent that went
away by itself (a crash, a kill, a Python that cannot import pi_agent_cli) went
unnoticed: nothing waited on the child, so the pager sat on requests that could not
be answered, and the event loop's "agent disconnected" arm (it quits when the
connection's cancel fires) never ran. A start that failed was no better: the reason
was the bridge thread's return value, which only the final join reads, so
`initialize` reported a closed channel and nothing else.

The bridge now waits on the child too. When it exits unasked, the bridge lets the
reader finish, fires the connection's cancel (the event loop quits), drops its tasks
(the pending requests fail instead of waiting for ever) and ends with an error that
names the program, how it ended and the last lines of its run in agent.stderr.log.
`connect()` returns that error when `initialize` fails, and the process guard prints
it after the terminal is restored when the agent went away mid-session. The pager's
own exit status is unchanged.

Found by the end-to-end test against the real agent (next commit): `false` as the
agent made connect() hang, and a program that does not exist was reported only as
"channel closed".

…plan 0.3)

tests/python_agent_e2e.rs drives pi_pager::acp::connect over real stdio against
`python -m pi_agent_cli` (mock model), without a pseudo-terminal: the handshake and
a clean stop; a streamed prompt; a session listed with its title and replayed by a
later agent; session/list followed by cursor (51 sessions, and an invalid cursor);
the permission question and both answers; cancel of a running tool, whose process is
reaped; a program that does not exist; an agent that exits at once; a Python without
pi_agent_cli; an agent killed in the middle of a turn.

PI_E2E_PYTHON names the interpreter. Without it the tests say so and pass; with
PI_E2E_REQUIRED=1 (set by tui-ci.yml) a missing interpreter is a failure, so a CI that
lost its Python is not green. The manifest runs the file in the pi-pager suite (10
tests on Linux, reference 5,587). tui-ci.yml installs the Python packages for it, and
also runs when the agent's own package changes.

…0.7)

scripts/tui_pty/resume_matrix.py makes one session through the TUI with the Python
agent, then starts zypi again with --continue, --resume <id>, --resume <title>,
--session-id and `zypi export`, and says whether each did what its help text promises.

Measured on WSL2 against a debug zypi: 9 cases hold and 4 do not. `--resume <title>`
finds nothing (it matches the old agent's summaries only), `--session-id` is ignored by
the Python agent and its in-use check cannot see Python sessions, and `export` says
"not found". The four are recorded as known gaps in the table (reported as GAP, and
--strict fails them) for the change that lands ADR1 to close; a gap that has closed
shows as FIXED until its text is dropped.

--continue works only because the pager's fallback reads the first line of each session
file and the Python header happens to carry the same `id` and `cwd` keys: format
knowledge the pager should not have.

The judging and the table are unit-tested in scripts/tests/test_tui_pty.py; those tests
need no zypi and run on any platform.

5,587 only added the new end-to-end tests to the last CI count. A local run of the
pi-pager suite through the baseline runner on Linux (scrubbed environment, the
end-to-end tests required, not skipped) passed 5,602 with 13 ignored: the 5,577
of CI run 38052332014, plus 10 end-to-end tests, 8 agent-exit tests, 6
fetch_session_list tests and the no-mcp_servers test. The next CI run confirms it.

…ours (plan 1.P3)

The TUI offers Normal, Always-Approve, Plan and Auto (Shift+Tab, --always-approve), and
tells the agent with a pi/yolo_mode_changed notification, or for Plan with session/set_mode.
The Python agent understands the notification only. mode_probe.py starts a fresh zypi per
way of choosing a mode against the scripted agent (permission mode ask, first turn calls
write) and prints whether a question appeared and whether the file was written unasked.

Today: Normal asks; --always-approve and Always-Approve do not; back to Normal asks again;
Plan asks and, once allowed, writes (it restricts nothing: set_mode is answered "method not
found" and the TUI only logs that); Auto never asks (the TUI describes a classifier that does
not exist behind the Python agent). The probe judges nothing; it is the evidence for plan
section 10.11 and the baseline a change to the mode mapping is compared with.

The probe covered the Shift+Tab cycle and --always-approve. `zypi --help` lists six values for
--permission-mode, and the probe now starts zypi with each of them.

On WSL2 only bypassPermissions changes anything: it behaves as --always-approve (status bar
"always-approve", no question, the file is written). default, acceptEdits, auto, dontAsk and plan
behave exactly as no flag at all: the status bar shows nothing and the write is asked about, so
acceptEdits does not accept edits, dontAsk does not stop asking, and plan does not enter Plan.

The reason is on the agent's side of the wire: the TUI puts yoloMode / autoMode in the _meta of
session/new, which the Python agent does not read. A mode chosen at the start works only where the
TUI answers permission questions itself (always-approve).

The probe still judges nothing; the plan (section 10.11) cites its table.

… a decision (plan r9)

The three gates still open after r8 (0.3 on the Rust side, 0.7, 0.8) are written down, together
with the parts of phase 1 that need no decision. Nothing here changes behaviour that was not
already committed; every behaviour-changing decision is a proposal for the user (section 10.11,
twelve items), not a change.

- docs/PLAN/PLAN-RUST-AGENT-RUNTIME-REMOVAL.md: section 10.11 (PR #9's second CI run, the e2e
  suite and the two product bugs it found, the cold-start latency before and after, the 13
  disk-read call sites in 8 files, the 13-case resume matrix, the landing design of ADR1 with the
  sandbox ordering and the PR slicing, the 12-scenario permission-mode probe, what changed, what
  was run, what was not, the twelve proposals); appendix A (capability matrix with every row
  marked decided / proposed / open, the ACP version pairing and the upgrade rules, the per-method
  table); B.4 (how to reproduce); the checklist ticks and the r9 revision-log line.
- docs/baselines/tui.md: pi-pager 5,577 -> 5,602 (the four new groups of tests), the full ten-suite
  run on WSL2 (8,659 passed / 0 failed / 22 ignored = CI's 8,634 + 25), the path-filter change.
- CHANGELOG.md, [Unreleased]: the session list is read in pages, the pager no longer sends
  mcp_servers and the agent says it ignores them, the agent-exit fixes.
- AGENTS.md: the resume matrix, the mode probe and python_agent_e2e.rs (PI_E2E_PYTHON).
  packages/pi-agent-cli/AGENTS.md: what the pager shows when the agent exits on its own.

Verification: scripts/tui_baseline.py test exits 0 (10 suites, 8,659 passed / 0 failed / 22
ignored); pytest 2,352 passed on Linux (WSL) and 2,351 on Windows; scripts/tests/test_tui_pty.py
19 passed with pyte; ruff check and ruff format --check clean with the venv's 0.16.10 and with
CI's pinned 0.16.0. All of it is WSL2's or Windows' own run; this branch has not been pushed, so
the first CI run confirms or corrects the numbers and the new e2e install step.