an output pane is not a document: +Search/+Help split below the pane that asked, never into a column of their own

placeDoc classified any file pane as a doc, so a +Search opened from a lone
shell took layoutInsertColumn(0) - a whole new leftmost column, shoving every
existing column sideways - and an open results list was then eligible as the
split parent for a real file, stacking documents under the list. An output
buffer has no file behind it and no Save; it is the result list belonging to
the pane that asked for it. Now it is that on both sides of the rule: it
splits below from_id whatever kind of pane that is (a source that died falls
back to stackDocLeft, the same last resort a full column bar uses), and it is
skipped when a real doc hunts for its split parent, so a file opened from a
search row joins the docs instead of the results.

Real docs are untouched: fsearch/rsearch/look-file/tutor/lookpanes all pass
unchanged. psearch is the proof - its results snap was two columns (the shell
pushed to x=70, its gutter run at 70-71) and is now one 140-wide column with
the +Search stacked below at the same x origin.

1 files changed, 4 insertions, 1 deletions

diff --git a/test/snapshots/find.snap b/test/snapshots/find.snap
index 28d5ebb2..03fefaa7 100644
--- a/test/snapshots/find.snap
+++ b/test/snapshots/find.snap
@@ -35,7 +35,10 @@ key enter
 wait 10000 zqmark-alpha.txt
 stable 700 15000
 snap results
-# n looks row 1 — a path, so the file OPENS — and focus comes back here
+# n looks row 1 — a path, so the file OPENS — and focus comes back here. The
+# look comes FROM the results buffer, but that is an output pane and not a
+# document, so the file joins the docs above it (below here.txt) instead of
+# stacking under the list: the +Search stays at the foot of the column.
 key n
 wait 10000 beta body
 stable 700 15000