clipboard, n/N and the tty prompt: three things that were half-wired

Three changes that all turned out to be the same shape -- a feature that
worked in one direction, or for one pane kind, and quietly did not in the
others.

CLIPBOARD. Every register write emitted set_clipboard, so deleting one
character threw away whatever the desktop was holding; multi-cursor yank took
the join's early return and emitted nothing at all, so the same key reached
the clipboard on one cursor and not on two. Nothing could READ the clipboard:
the SDL shell had no SDL_GetClipboardText anywhere in it, and the tty shell
never asked for OSC 52, so `p` from another application was dead in both.

Now it is helix's split. y/d/c/p/P/R and the acme chords are the DEFAULT
REGISTER and nothing else; the system clipboard is five words on helix's own
letters -- SPC y, SPC Y, SPC p, SPC P, SPC R -- spelled as builtins so they
land in Help and are executable like every other verb. The one exception is
the tag `y` chord, which still mirrors out because a tag is always insert, so
SPC cannot be pressed there, and copying the path out is the whole point of
the chord.

Reading is a new read_clipboard effect answered by an ordinary Event.paste, so
the round trip is honest about being one: SDL and NSPasteboard answer inside
the same drain, the browser answers a promise, and a terminal answers over
OSC 52 or -- far more often -- refuses. A refused read is a paste that does
not happen, and the request dies at the next keystroke rather than landing
minutes late in whatever pane is focused by then.

The tty shell also enables BRACKETED PASTE now and coalesces
paste_start..paste_end into one event. Before this a paste arrived as a flood
of individual key presses: plausible in insert mode, and in normal mode every
pasted character ran as a command.

n/N. They stepped the armed results buffer and immediately Looked each row, so
you could not walk past a hit without opening it. They are a MOTION now:
select the next look-able text, open nothing, and let Enter decide. What they
step is the largest whitespace-delimited run look.resolve can act on
(look.lookableSpan, wrapper punctuation peeled), over a RING of panes -- every
pane that has performed a look, most recent first, then the output buffers
that have not, newest first, and only if both are empty the pane in front of
you. N is the exact inverse of n, computed rather than remembered: both
directions ask the same question about the same spans and compare against the
column the walk parks on, so x presses one way and x back land exactly where
you started, pane boundaries and the ring's seam included.

A ring rather than a list with two ends because a shell's cursor sits at the
prompt, below everything it has printed, so a walk that could not come round
would have nowhere to go on the very first press -- which is the case n/N were
written for.

One motion everywhere, no pane-kind or buffer-kind special case. The only
thing a buffer may change is the GRAIN of what a step selects, and it does it
with one flag rather than a branch: output_pane.Traits.commands (renamed from
`executes`, which named one reader's behaviour rather than the fact) makes a
row select WHOLE, because a ThemeSel line is a word to run and has no path
inside it to pick out. `]d`/`[d` are not n/N -- they are helix's diagnostic
motions, their job is to ARRIVE, and they still reach searchStep.

THE TTY PROMPT. Leaving raw tty blanked the prompt row, and the command you
had typed at that prompt shares the row, so it went too -- a shell out of tty
read as output only. OSC 133 marks the row CELL by cell, so the two are
separable: config.tty_blank = .prompt cuts the prompt's own columns and leaves
the command, left-hugged at column 0 in line with the output under it rather
than in a bay of blanks. .prompt_and_input is the old behaviour, kept.

Because the row is now something you can put a cursor in, enterTty adds the
hidden prompt width back before asking ghostty to walk the shell's own cursor
to it -- the modal column on a cut row is short by exactly that much.

Verified: unit-test 186/186 (nine new), snap 87/87 (new ttyprompt.snap),
hxdiff 481 and hxparity 561 with 0 mismatches, tty and gui both build. And
against the real binaries rather than the harness: in a pty, SPC y emits OSC
52 carrying exactly the selection while plain y emits nothing, SPC p issues
the read and pastes the reply, and a bracketed paste of "dd..." inserts text
instead of deleting two lines. In a real SDL window, SPC y then SPC p round
trips through the system clipboard while the default register holds different
text. Setting tty_blank back to .prompt_and_input reproduces all 86 old
goldens byte for byte.

1 files changed, 44 insertions, 19 deletions

diff --git a/test/snapshots/find.snap b/test/snapshots/find.snap
index 1fd36aa6..8f288525 100644
--- a/test/snapshots/find.snap
+++ b/test/snapshots/find.snap
@@ -1,11 +1,13 @@
 # The Find builtin (SPC f f) = `fd`, in-core: it arms the SAME tag input `/`
 # does, but Enter walks the pane's DIRECTORY instead of its text and writes one
 # matching path per row into a "+Search" OUTPUT BUFFER. Every row is therefore
-# an ordinary look target, which is the whole point: n/N step the rows and look
-# them with no code of their own, opening each found file, and focus returns to
-# the pane that owns the search so the next n keeps stepping. The walk skips
-# .git, matches the NAME case-insensitively, and sorts (readdir order is not
-# stable). `SPC f s` is Save, which moved out of `w` to make this group.
+# an ordinary look target, which is the whole point: n/N SELECT the next/prev
+# one with no code of their own, and the look chord — Enter, the same one that
+# opens a path anywhere else — is what OPENS it. Focus then follows the file
+# that opened, but the look was made FROM the results buffer, so the next n
+# resumes stepping that same list. The walk skips .git, matches the NAME
+# case-insensitively, and sorts (readdir order is not stable). `SPC f s` is
+# Save, which moved out of `w` to make this group.
 dirmk sub
 dirmk sub/nest
 dirmk .git
@@ -35,25 +37,30 @@ 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. The
-# look comes FROM the results buffer, but that is an output pane and not a
+# n SELECTS row 1 and Enter looks it — a path, so the file OPENS. 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
+key enter
 wait 10000 beta body
 stable 700 15000
 snap first
 snapstyle first
 key n
+key enter
 wait 10000 gamma body
 stable 700 15000
 snap second
 key n
+key enter
 wait 10000 alpha body
 stable 700 15000
 snap third
-# N walks back up: the file is already open, so the look just focuses it
+# N walks back up one row; Enter looks it, and the file is already open, so
+# the look just focuses it
 key N
+key enter
 stable 700 15000
 snap back
 # executing the WORD Find (middle-click in a body) arms the same input — the
@@ -66,23 +73,39 @@ key esc
 settle 100
 stable 400 5000
 snap cancel
-# a no-match walk opens an empty list; n then has nowhere to go. The list is
-# exactly as tall as its results — one blank row plus its tag — and it stacks
-# above the earlier one, whose height is untouched.
+# every search is asked from a PANE, and both a look and now a step leave you
+# somewhere else — so click back into here.txt first. That is not bookkeeping:
+# a search never refills the buffer it was asked FROM (fillResults skips it),
+# so `owned by here.txt` is the whole premise of the two steps below.
+press left 8 3
+release left 8 3
+stable 400 5000
+# a no-match walk opens an empty list of its own. It is exactly as tall as its
+# results — one blank row plus its tag — and it stacks above the earlier one,
+# whose height is untouched.
 key space
 key f
 key f
 text zzqq
 key enter
 stable 700 10000
+# n does not stop on the empty list, because the walk is a RING across panes
+# rather than one buffer's rows: with nothing look-able here it carries on
+# into the list that DOES have some — the zqm one — and resumes it one row
+# past where the N above left it. Nothing opens; only the selection moved.
 key n
 stable 400 5000
 snap nomatch
 # ... and asking for `zqm` AGAIN re-arms the list it ALREADY filled instead of
-# stacking an identical twin under the empty one — even though n/N were armed
-# on the zzqq list, so the reuse is by what a buffer HOLDS (this search, this
-# pattern, this directory), not by which one the pane happens to point at. The
-# frame is therefore the `results` frame unchanged, down to the byte.
+# stacking an identical twin under the empty one — even though the step above
+# left the cursor sitting in the zqm list, so the reuse is by what a buffer
+# HOLDS (this search, this pattern, this directory), not by which one anything
+# happens to point at. Asked from here.txt again (the click, as above), and
+# the LIST it rewrites is therefore the `nomatch` frame unchanged, down to the
+# byte — only the cursor comes back with it.
+press left 8 3
+release left 8 3
+stable 400 5000
 key space
 key f
 key f
@@ -94,10 +117,12 @@ snap refit
 # Find is a TOPBAR word too (row 1, its own column, next to Grep): the same
 # builtin the leader path runs, reached with the mouse. Chorded — a selection
 # held when it runs IS the argument — so dragging over `alpha` and clicking
-# Find walks for that name with nothing typed and no input armed.
-press left 8 8
-drag left 13 8
-release left 13 8
+# Find walks for that name with nothing typed and no input armed. Row 34 is
+# `alpha body`: the three found files stack in the order the looks above
+# OPENED them, which is beta, gamma, alpha down the column.
+press left 8 34
+drag left 13 34
+release left 13 34
 stable 400 5000
 press middle 12 1
 release middle 12 1