acmefs: a pane's terminal gets pty/data, pty/ctl and pty/status

Step 3 of the 9P chain (docs/9p.typ 12.3, docs/registry.typ 9P-8). Nothing here
is about 9P: it lands in the FUSE-served tree and any later transport inherits it.

A script could write into a terminal that already existed and read its rendered
scrollback. It could not START one, RESIZE one or SIGNAL one. Two of those were
already effects the core emits, so `exec` and `winsize` are existing
capabilities acquiring a name; only `sig` is new, and it brings the one new
host method, `push_pty_signal`.

  pty/ctl     winsize <cols> <rows> | sig INT|TERM|HUP|QUIT|KILL | exec
              one verb per line, validate-all then apply-all, EINVAL applies
              nothing -- `writeCtl`'s shape and `writeCtl`'s reason
  pty/status  cols, rows, tty-taken as three %11d fields
  pty/data    write is input to the process; read is the RAW output stream,
              gated on a reader count so a pane nobody reads costs one branch

A pane that is not a terminal has no pty/ at all: the lookup is ENOENT and
readdir does not list it.

`PaneFile` is an enum(u4) and this takes it from 11 values to 15. ONE REMAINS.
That is also why pty/ is a DIRECTORY and not three more flat names -- a
subdirectory costs one value and buys its own namespace, so `ctl` and `data`
did not have to be renamed.

Two things the core does not know, and which are therefore not invented: a
child's EXIT STATUS (a shell's death is `Event.eof`, which removes the pane,
so there is no directory left to read it in) and RAW/COOKED (the core never
sets a termios; the mode belongs to the program on the far side).

Verified live against a daemon: pty/ appears only on the terminal pane; a
`winsize 0 24` and a `sig SIGINT` are refused; a bad verb beside a good one
applies neither; `echo pty-works` written to pty/data runs in the shell and its
output reaches the body; and a blocking read of pty/data returns the raw stream,
OSC 133 marks and all. fs-bench unchanged and still zero allocations.

1 files changed, 8 insertions, 0 deletions

diff --git a/src/gui/gui.zig b/src/gui/gui.zig
index da48d3fb..f7c4c51c 100644
--- a/src/gui/gui.zig
+++ b/src/gui/gui.zig
@@ -3579,6 +3579,7 @@ const Shell = struct {
         .push_spawn = spawnPane,
         .push_pty_write = ptyWrite,
         .push_pty_resize = ptyResize,
+        .push_pty_signal = ptySignal,
         .pull_tty_taken = ttyTaken,
         .push_write_file = writeFile,
         .push_write_dump = writeDump,
@@ -3917,6 +3918,13 @@ fn ptyResize(ctx: ?*anyopaque, pane: u8, cols: u16, rows: u16) void {
     }
 }
 
+/// `pty/ctl`'s `sig`. A pane with no pty of ours has nothing to signal, which
+/// is the same silence `ptyWrite` above gives it.
+fn ptySignal(ctx: ?*anyopaque, pane: u8, sig: pardes.PtySignal) void {
+    const s = shellOf(ctx);
+    if (s.ptys[pane]) |pt| look.signalTty(pt.pid, pt.fd, sig);
+}
+
 /// Is a program (vim, a pager, an agent) holding this pane's tty instead of
 /// the shell we forked? Asked by the core only where it is about to type a
 /// command line, which is why the /proc walk behind it is not in pollCwds: