build: pardes builds without the ESP32-P4 toolchain checkout beside it

`build.zig.zon` named `../05-zig-p4` as a path dependency, and `build.zig`
`@import`ed it inside `if (-Desp32p4-firmware)`. But `@import` in a build script
is resolved when the SCRIPT is compiled, not when the branch that needs it is
taken -- so naming the package at all meant anyone without that sibling checkout
could not build pardes AT ALL. Not the firmware: the terminal shell, the SDL
shell, the tests. `zig build` failed with

    build.zig:1073: error: no module named 'zig_p4' available within module 'root.@build'

from a line inside an `if` that was false.

Neither escape hatch works for a PATH dependency, and both were tried rather
than assumed. `.lazy = true` is about FETCHING; a path dep whose directory is
absent is generated as a package with no `build.zig` rather than one marked
unavailable, so `b.lazyImport` -- which exists for exactly this and is what the
standard library says is to `@import` what `lazyDependency` is to `dependency`
-- reaches a `@compileError` instead of returning null. Making it a fetched
dependency instead is not available either: the toolchain has no remote.

So the duplicate goes. That build tree's firmware block linked an image the
toolchain repository already knows how to link -- its own build.zig has
`-Dpardes`, `-Dapp=<root>` and `-Dpardes-obj=<path>`, and its comments record
having learned this same lesson from the other direction, where nesting pardes's
~30-package graph under it broke every build there. The object is the seam: it
crosses by PATH and never by package, and each repository builds what it owns
the pieces of.

  zig build -Dplatform=esp32p4                    # here, no toolchain needed
  zig build -Dpardes                              # there, the console image
  zig build -Dpardes -Dapp=<pardes>/src/esp32p4_9p.zig   # there, the 9P image

For the second and third to work with no module map, `src/board9p.zig` and the
9P firmware root now reach the codec by PATH instead of through a named `ninep`
module that only pardes's own build.zig knew to inject -- which is also why the
root moved from `src/esp32p4/nine.zig` up to `src/esp32p4_9p.zig`, beside
`src/esp32p4.zig`: a path import may not escape its module's own directory. Both
files are now self-contained, and `zig test src/board9p.zig` works with no flags.

`-Desp32p4-port`, `-Desp32p4-prof` and `-Desp32p4-cpu-mhz` go with the block. An
option this build cannot honour is worse than no option, because it accepts the
flag and then ignores it; all three are spelled the same way in the toolchain.

Verified by moving ../05-zig-p4 out of the way: `zig build`, `zig build
-Dplatform=esp32p4` and `zig build unit-test` all pass without it. With it back,
the toolchain still links both images -- console 812,720 B, 9P 88,096 B.

next-steps.txt gains the six features the 9P chain shipped.

1 files changed, 50 insertions, 0 deletions

diff --git a/next-steps.txt b/next-steps.txt
index 3546da42..60605edc 100644
--- a/next-steps.txt
+++ b/next-steps.txt
@@ -2,6 +2,56 @@ WHAT THIS IS: a wishlist, in the author's own words. The items below are left
 exactly as written; this header is the only thing kept in sync with the code,
 because a list that reports shipped work as pending is worse than no list.
 
+9P (docs/9p.typ is the note, docs/registry.typ the argument). SIX NEW THINGS,
+each verified against a running program and not assumed:
+
+1. A DETACHED SESSION CAN BE SCRIPTED. `pardes --detach=work --fs` mounts its
+   own /dev/fuse and polls it in the same poll(2) as its frontends and pane
+   shells, so it needs no wake thread — less than the desktop shells pay. The
+   one configuration whose panes outlive every terminal was the one no script
+   could reach. Proof: examples/acmefs/pardesctl panes|new|send|body|del.
+
+2. TERMINALS ARE SCRIPTABLE. Every terminal pane grows `pty/ctl`, `pty/status`
+   and `pty/data`. `winsize 80 24`, `sig INT|TERM|HUP|QUIT|KILL`, `exec`; a
+   write to `pty/data` is input to the process and a read is its RAW output,
+   escape sequences and all. A script could only ever write into a terminal
+   that already existed; now it can start one, resize one and signal one.
+
+3. THE TREE IS SERVED OVER 9P. `--fs9` puts acme's control filesystem on a unix
+   socket as base 9P2000 (src/9p.zig — codec and a sans-io server, no threads,
+   no allocator, builds freestanding). plan9port drives it: `9p -a <sock> ls /`,
+   `read /index`, `write /1/body`, `stat`, a walk through `..`. Errors come back
+   as STRINGS Linux's table knows, not numbers. `--fs` and `--fs9` serve the
+   same tree at once: a write over one reads back through the other.
+
+4. A PATHNAME WITHOUT MOUNTING ANYTHING OURSELVES. `9pfuse <sock> <dir>` and
+   ordinary tools work — ls -l with the right modes, cat, shell `>>`, permission
+   denied on the write-only files. That is the route macOS and the browser take,
+   neither of which has ever had a control filesystem.
+
+5. ONE PARDES READS ANOTHER. The `9p <dial> <path>` word walks another
+   instance's tree and opens the bytes in a pane. Before this, two instances
+   could shout one line at each other (nested.zig, write-only, no reply) or
+   REPLACE one another (`Attach` deinits the local core); they could not ask a
+   question. Proof: B read A's /1/body byte-identically to plan9port.
+
+6. THE BOARD SERVES ITS OWN TREE. A second ESP32-P4 image where UART0 carries
+   9P and nothing else — no ANSI, no vaxis, no allocator — 88 KB against the
+   console image's 809 KB. Its GPIO tree comes from a comptime table
+   (src/board9p.zig) that is the single description: one entry fans out to a
+   directory per pin. The console firmware is untouched and still what
+   `-Dplatform=esp32p4` feeds. No board was attached, so only what builds and
+   what the host tests cover is claimed.
+
+AND ONE THING THAT WENT AWAY: pardes no longer depends on the ../05-zig-p4
+toolchain checkout to build. It used to be a path dependency named in
+build.zig.zon, and because `@import` in a build script resolves when the SCRIPT
+compiles rather than when the branch needing it is taken, anyone without that
+sibling could not build pardes at all — not the firmware, the terminal shell.
+The object is the seam: `-Dplatform=esp32p4` emits it here with no toolchain,
+and the toolchain repository links the flashable images, which it already knew
+how to do.
+
 SHIPPED (verified against the tree, not assumed):
 - "version tracking" -> done. `build.zig` reads `.version` from build.zig.zon
   via an untyped `@import`, `gitCommit(b)` reads the commit at configure time,