A Rename that previews other files answers its preview pane to the 9P write that asked it, and says on the message row that it previewed and applied nothing

A multi-file Rename filled a +Search preview but the waiting exec write
answered the pane it was asked from, and nothing was said. lspResponse
now notes the pane it filled (fs.lsp_result); the write that waited for
the answer reads that pane back, as a look or an exec answers the pane
it went to, and the message row says `Rename: N edit(s) across files,
previewed, not applied`.

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

1 files changed, 13 insertions, 0 deletions

diff --git a/src/9p_io.zig b/src/9p_io.zig
index ea3f799c..a4340ddf 100644
--- a/src/9p_io.zig
+++ b/src/9p_io.zig
@@ -317,7 +317,20 @@ pub const Listener = struct {
         if (core.effects_len != 0) pardes.turn.awaitSettled(epoch);
         if (core.fs.lsp_answer_at) |n| {
             core.fs.lsp_answer_at = null;
+            core.fs.lsp_result = null;
             pardes.turn.awaitLsp(n);
+            // The answer filled a pane (a Rename's preview): that is what
+            // this write's open reads back, as look and exec answer.
+            if (l.core == core) if (core.fs.lsp_result) |serial| {
+                core.fs.lsp_result = null;
+                core.fs.results[0] = serial;
+                core.fs.results_len = 1;
+                if (pardes.ctlfs.openOf(core, req)) |o| {
+                    o.results.list[0] = serial;
+                    o.results.len = 1;
+                    o.results.read = 0;
+                }
+            };
         }
         core.fs.write_waits = false;
         // ponytail: one slot, so a failure of another client's effects that