docs: the log's restore record, not the Restore write's answer, says a Restore happened

The answer gets 200 ms to leave before the connections are cut, so a slow
client may see only the cut; the new log's 'restore <path>' record is what to
trust.

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 ae5e27ad..7361c19e 100644
--- a/docs/fs.md
+++ b/docs/fs.md
@@ -116,7 +116,9 @@ and logs `dump <path>`, and `Restore` with no path takes the last one; a
 Restore puts a new editor under every client, so the write of it is
 answered and then every connection is hung up, their fids naming the old
 editor's panes: dial again, and the new log names the restored panes and
-`restore <path>`. Keeping connections across it would mean carrying serials
+`restore <path>`. The answer has 200 ms to leave before the cut, so a slow
+client may see only the cut; the log's `restore <path>` is what says the
+Restore happened. Keeping connections across it would mean carrying serials
 and opens into the new editor, which acme, whose Load only adds windows,
 never needed); and `Kill`, which
 does not quit but stops commands, as acme's does: bare, every command pardes