A name written whole with no newline is checked with its write, as the docs now say, not at the close

Round 24's no-newline rule (uwzuqzxp) already covers name, a lines file; the 9P monkey's close_runs_only_line_files repros were from a binary before it. This pins it with a test and corrects docs/fs.md, which still said such a name waited for the close.

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

1 files changed, 3 insertions, 2 deletions

diff --git a/docs/fs.md b/docs/fs.md
index af64fded..760693e5 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -574,8 +574,9 @@ directory. A name alone is no edit: the pane's `dirty` stays what its text made
 (a renamed clean file is still 0, and nothing asks about it at Exit,
 Restore or Del, which ask only about text edited), and `Save` writes it
 under the new name all the same. An open's writes are one name: held
-until its newline, or its close when it has none, then applied once, however
-the writes cut it; nothing else is trimmed. Two lines are refused, EINVAL,
+until its newline, applied once however the writes cut it; a write with
+no newline that is whole in its Twrite is the name then, so a bad one fails
+that write, not the close. Nothing else is trimmed. Two lines are refused, EINVAL,
 in one write or as a second line on the same open (bash's `printf
 'a\nb\n' > name` writes a line at a time: the first names it). A blank inside a name is taken
 (`two words.zig`); refused, EINVAL, in acme's words (xfid.c:650) and why,