docs: through a mount a malformed write is EINVAL and one that fails is EIO, and the error words keep it so

The served README said every refused write reads as EINVAL, but a mount's
errno is 9ns's reading of the error's words, so a no-match or out-of-range
address and a refused Exit came back EIO, as the dogfood run saw. That split
is the useful one, malformed against failed, so the docs now state it rather
than the words being bent to EINVAL; a test pins each error's words to its
side of it. It caught one: 'regular expression search took too long' read as
ENAMETOOLONG, and now says it gave up past its step budget.

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

1 files changed, 14 insertions, 6 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 96d0eb3a..4673e042 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -151,9 +151,9 @@ and `not a session control message "X"` or `not a window control message
 "X"` for a word of the other ctl. 9ns maps them all to EINVAL, and a write
 refused here has done nothing. A line that then fails as it runs fails the
 write with the error the editor reports for it and the line, e.g. `Mount:
-AlreadyMounted "Mount peer /tmp/s"` (EIO); so does `control message needs
-its argument "Save"`, for a builtin that would have asked at a prompt (a
-`Save` on a scratch) rather than open one nobody is there to answer. The
+AlreadyMounted "Mount peer /tmp/s"` (EIO), and `control message needs its
+argument "Save"` (EINVAL), for a builtin that would have asked at a prompt
+(a `Save` on a scratch) rather than open one nobody is there to answer. The
 lines before a failing one have taken effect and those after it never run,
 which is what acme's ctl loop does (editors/acme/xfid.c:600-790). An error
 that only happens as the editor performs what a line asked for -- a `Save`
@@ -314,7 +314,8 @@ pattern that spans lines, `^`, `$` and `[^...]` keep mvzr's own meaning.
 mvzr backtracks without bound of its own (`a?` twenty times then twenty
 `a`s is 2^20 steps from each place it tries), and a search holds the editor, so pardes patches a
 step budget into mvzr's matcher (build.zig): a search that spends it,
-about 300 ms, fails with `regular expression search took too long` rather
+about 300 ms, fails with `regular expression search gave up, backtracking
+past its step budget` rather
 than answer a match it is not sure of. Ordinary patterns spend a few
 thousand steps; what runs out is exponential backtracking, and a quadratic
 pattern over a very long line (`\s*(\w+)\s*=` over 20 KB of letters).
@@ -324,7 +325,7 @@ is the one place both call), so `^` there also means a line's start.
 
 An address that does not evaluate fails the write with why: `bad address
 syntax`, `no match for regexp`, `address out of range`, `bad regular
-expression`, `regular expression search took too long`, or sam's
+expression`, `regular expression search gave up, ...`, or sam's
 `addresses out of order` for a range that ends before it starts
 (`#100,#50`), which acme lets through. A failed write to `addr` leaves no
 address at all, where acme
@@ -370,7 +371,14 @@ reply to, usually `Invalid argument`, and this is the reason (`err 3 addr:
 no match for regexp`). The same err again, before any follower has read
 the first, is that record counted (`err 3 addr: no match for regexp (x4)`),
 so a client retrying a failing write does not push the rest out of the
-ring; a follower that read it gets each repeat. There is no per-pane error file to read instead:
+ring; a follower that read it gets each repeat. Through a kernel mount a client sees only an errno, which 9ns reads from the
+error's words (cloud9's 9ns/src/nine.zig, `enameToErrno`): a malformed write
+-- an unknown or ill-formed control message, `bad address syntax`, `bad
+regular expression` -- is EINVAL; a lock another open holds, EBUSY; a pane
+gone, ENOENT; a well-formed write that fails -- `no match for regexp`,
+`address out of range`, `addresses out of order`, a search that gave up,
+`<name>: Modified (Exit again to discard)` -- EIO. The err record has the
+words. There is no per-pane error file to read instead:
 acme's `errors` only takes text, and one record stream is simpler to watch
 than a file per pane. A `msg` said while a
 pane is being made can precede that pane's `new`; panes present at boot are