A Save the host cannot do fails the 9P write that asked for it, and the log names the path and why

The write answered ok and the pane stayed dirty, with `save: AccessDenied` on its message row: a script saw success. The failure now says `Save <path>: <why>`, and a 9P write that waited on the save fails with EIO and that text, logged as an err record.

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

1 files changed, 8 insertions, 0 deletions

diff --git a/src/9p_io.zig b/src/9p_io.zig
index 2ca11a87..6bd03049 100644
--- a/src/9p_io.zig
+++ b/src/9p_io.zig
@@ -296,7 +296,15 @@ pub const Listener = struct {
         // Set with the turn still held, so `reset` sees it and waits.
         if (restoring) l.restore_writer.store(true, .release);
         defer if (restoring) l.restore_writer.store(false, .release);
+        core.fs.late_failure_len = 0;
         if (core.effects_len != 0) pardes.turn.awaitSettled(epoch);
+        // ponytail: one slot, so a failure of another client's effects that
+        // settle in the same wait is told to this write too.
+        if (l.core == core and core.fs.late_failure_len != 0) {
+            const failed = pardes.ctlfs.failText(req.tag, pardes.ctlfs.E.IO, core.fs.late_failure[0..core.fs.late_failure_len]);
+            pardes.ctlfs.events.noteError(core, req, failed);
+            return conn.reply(&failed, "");
+        }
         // The Restore's own write is answered once it is done, and before
         // `reset` hangs every connection up, this one too, so the writer
         // hears that it happened rather than a cut; a failed one leaves the