9harness: drop the zmxify script; the mount is the replacement

The script listed /active, ran fzf over it and wrote the chosen name
into an agent's zmx. Everything in it but the picker, a free-name loop
and the attach was `ls` and `cat` against the tree — 130 lines
re-deriving what four lines of shell already read:

  ls /mnt/9p/harness/active/*/*
  cat /mnt/9p/harness/active/claude/345104/session
  echo mine > /mnt/9p/harness/active/claude/345104/zmx
  zmx attach mine

zmxify was 307 lines of rc because there was no filesystem to ask. The
answer to that is the filesystem, not a smaller script on top of it,
which would only become a second and worse interface beside the real
one. DESIGN.md keeps what a caller now arranges itself (a free name,
the attach) and why the old script's own-ancestry rule is gone rather
than moved.

1 files changed, 28 insertions, 20 deletions

diff --git a/9harness/docs/DESIGN.md b/9harness/docs/DESIGN.md
index 4868bc8..340f3da 100644
--- a/9harness/docs/DESIGN.md
+++ b/9harness/docs/DESIGN.md
@@ -390,29 +390,37 @@ Named, because they are choices rather than oversights:
 
 ### Replacing zmxify
 
-`9harness/zmxify` is the whole script now: it lists `/active`, offers
-the rows to fzf, and writes the chosen name into the agent's `zmx`.
-It parses no `/proc`, opens no fd table and queries no database — the
-307 lines that did become a `cat` of a few files, and the knowledge
-they held now lives in a daemon with tests around it.
+There is no replacement script, because the mount is the replacement:
 
-What the script still decides is which rows to offer and what to call
-the new session. It skips an agent already under zmx — that is what
-this moves things *into* — and one whose session did not resolve, which
-the daemon would refuse anyway. A free name is the caller's business
-too, and the registry already answers which are taken.
+```
+ls /mnt/9p/harness/active/*/*                     what is running
+cat /mnt/9p/harness/active/claude/345104/session  what it is
+echo mine > /mnt/9p/harness/active/claude/345104/zmx
+zmx attach mine
+```
+
+`~/.local/bin/zmxify` was 307 lines of rc because there was no
+filesystem to ask: it scanned `/proc`, classified command lines, read
+fd tables and queried two sqlite databases to work out what the four
+lines above now read. All of that moved into the daemon, where it is
+tested. Writing a wrapper back on top would only re-derive what the
+tree already says, and would become a second, worse interface beside
+the real one.
+
+Two behaviours the old script had are worth knowing, because they are
+now the caller's to arrange and both are one line: pick a session name
+nothing holds (the registry, `$XDG_RUNTIME_DIR/9p/zmx`, says which are
+taken) and `zmx attach` afterwards.
 
-What it does **not** skip is the caller's own session, and that is the
-whole point of the daemon owning the action. The old script excluded
-its own ancestry because it did the killing itself: kill your own
+A third is gone rather than moved. The old script refused to act on
+its own ancestry, because it did the killing itself: kill your own
 parent and the script dies before it can re-exec, losing the session it
-was rescuing. Now the script's only job is to get the `Twrite` out.
-The daemon kills, re-execs and waits for the new session to post, and
-it completes all of that whether or not the client is still there —
-verified by hanging up immediately after sending the write and watching
-the move land anyway. So zmxifying the terminal you are sitting in
-works; the shell drops, and `zmx attach <name>` is printed before the
-write, because there may be no script left to print it after.
+was rescuing. The daemon kills, re-execs and waits for the new session
+to post, and completes all of it whether or not the client is still
+connected — verified by hanging up immediately after sending the write
+and watching the move land anyway. So moving the terminal you are
+sitting in works, which is the common case; the shell drops, and you
+reattach with the name you wrote.
 
 ### Testability