A command pane's command is over when its process exits, not when its pty closes

A job left in the background (sleep 100 &) held the pty open, so the pane
stayed running and the child a zombie until the job ended; a command that
closed its terminal and ran on got its end of file at once, the host waited
100 ms for an exit, reported exit ? and hung it up. Now each command's child
is watched on a thread (waitid with WNOWAIT, so its pid stays its own until
the host reaps it), and the host tells the core the exit from that: after the
pty's end of file, so the output before the exit is in, or 50 ms after the
exit without one, a job holding the pty. The pty stays open until both, so a
command that let go of its terminal is never hung up by it. All four front
ends; a host that cannot start the watcher reads the exit at end of file as
before. Tests: host_io's for both cases, and cmdexit.snap end to end.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

1 files changed, 4 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index ebc85f12..d3e32e3a 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -238,7 +238,10 @@ same tree without leaving the process.
   a terminal whose tty a program holds -- it runs as a command pane: a
   terminal whose child is `$SHELL -c` the line in the pane's directory,
   which shows its output and then `exit N` (its tag reads `<dir> (<line>)
-  running`, then `exit N`), and stays. The directory's next command runs in
+  running`, then `exit N`), and stays. The command is over when its process
+  exits, as in acme, not when its terminal closes: a job it left in the
+  background prints on below `exit N` until it lets go of the pty, and a
+  command that lets go of its terminal early runs on to its own exit. The directory's next command runs in
   that pane once it is done, below what it showed, after a `% <line>` line;
   one still running gets a second pane. Before the next command the pane
   leaves any alternate screen and turns off the modes a program left on