Lspinfo's exec answer is the +Lsp pane it fills: any language answer that fills a pane answers that pane, made or filled again

The answer was taken from the asking pane's search pane, which a
listing like +Lsp never sets, so Lspinfo answered the file pane. The
pane the answer filled is now known from what fillResults made or
refilled, whatever kind of listing it is.

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

1 files changed, 10 insertions, 0 deletions

diff --git a/src/ninep/ctl.zig b/src/ninep/ctl.zig
index 3b3873e3..5827a4ed 100644
--- a/src/ninep/ctl.zig
+++ b/src/ninep/ctl.zig
@@ -4294,3 +4294,13 @@ test "Find ends with what it skipped, and a Find or Grep that finds nothing leav
     try testing.expectEqualStrings(before, search.file.?.content);
     try testing.expect(th.logHas(p, "Find: name not found"));
 }
+
+test "Lspinfo's answer is the +Lsp pane it fills, as a Rename preview's is its +Search" {
+    const p = try withFile(testing.allocator, "x\n");
+    defer p.deinit();
+    p.fs.lsp_result = null;
+    p.lspRequest(p.active, .status, "");
+    p.lspResponse(p.lsp_wait.?.id, "backend: lsp-client\n");
+    const shown = p.paneBySerial(p.fs.lsp_result.?).?;
+    try testing.expect(std.mem.endsWith(u8, p.panes[shown].?.file.?.path, "+Lsp"));
+}