fs.md says that in a > to a tag cut into several writes, those taken before a refused one stand

A `>` to a tag that a client sends in several writes is checked a write
at a time. When a later one is refused, the earlier accepted ones stay in
the tag. Buffering the whole open to apply it or none would cost more
than it saves, so fs.md now says what happens: each write stands on its
own, and only the refused one changes nothing. A test covers a
truncation, an accepted write, then a refused one.

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

1 files changed, 3 insertions, 1 deletions

diff --git a/docs/fs.md b/docs/fs.md
index 0ec88876..dacb49ba 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -371,7 +371,9 @@ non-UTF-8 bytes are refused (`invalid tag text`). The editable text is at
 most 4096 bytes (`no space: over 4096 bytes`, ENOSPC; the log says `err <serial> tag: no space: ...`). All three kinds
 take the same checks, whole or not at all, and a `>` whose write is refused
 changes nothing: its truncation is done with the write that fits, or at the
-close (or a read) when none came. A clear is an ordinary edit
+close (or a read) when none came. Each write stands on its own: in a `>`
+cut into several writes, those taken before a refused one stay in the
+tag; only the refused write changes nothing. A clear is an ordinary edit
 and `u` in the tag undoes it. [tags.md](tags.md) covers tags on screen.
 
 ## Panes