sl0ppty: the middle of a border is the button, not all of it

Clicking a pane's border to split toward it is the right gesture and was the
wrong target. A border is the longest thing on the screen and it sits between
two things you did mean to click -- a title, a gap, the pane beyond it -- so
reaching a cell too far changed the layout, and the top row was worse than the
sides: clicking a pane's header to focus it split it upward.

So the target shrank. Each side carries a *handle* of three to seven cells in the
middle, and only the handle splits; the rest of the edge is the *rim*, which
arms the guide and does nothing when pressed. Three is the floor the pane
buttons already settled on for the reason written there -- a one-cell target is
a thing you miss with a mouse -- and seven is the ceiling, because a third of a
tall pane's border is most of that border again and brings the accidents back
with it.

Hover now answers two questions in two stages, because they are two questions.
Anywhere on an edge, the edge goes heavy and the handle thickens by a cell into
the pane: that says where the button is, which is the thing you can no longer
infer. On the handle, the dashed boundary and the arrow as well: that says what
the click will do. The hint follows the same split, so sweeping an edge neither
draws a boundary nor offers a split you cannot get from where the pointer is.

Three things this had to get right.

**The thickened handle is registered, not just painted.** The guide adds the
hit for the inner strip in the frame that draws it, and reads the outer rect
back from the hit list rather than recomputing it, so there is one opinion about
where the handle is (D6). A handle you can see and cannot click would be worse
than either mistake alone.

**The top row cannot put its handle in the middle.** The buttons own its right
and a centred title -- the default -- owns exactly the middle. The title winning
is the existing rule, and it is what keeps a double-click rename from splitting
twice on its way, so the handle is placed last, in the widest run of cells the
row has left and nearest the middle among equals. A row with nothing left offers
no upward split; its other three edges are unaffected. Each handle cell is then
painted only if the hit list still agrees it belongs to the handle, so a block
never lands on a pane's name.

**The row keeps the drag and loses the split.** `title:<id>` takes no side now
and `title:<id>:t` -- the handle -- carries one, which is why the press path
reads the side out of the action instead of assuming it. Press-and-hold skips
the dwell on a handle, where a press means something, rather than anywhere on an
edge.

Verified: `make retest`, 1801 checks, all green. Nine of them are new or
rewritten: the two-stage guide, the caption belonging to the handle, the rim
splitting nothing on any of the four sides, the top row's handle still splitting
upward on a titled pane, and the rim of the top row not. Tests read the handle's
cell out of the hit list (`Snapshot.handle`/`.rim`) rather than deriving the
geometry, so a test cannot agree with a broken formula.

Also checked by hand on a live session, which is where the placement rule earned
itself: hovering the rim draws the heavy edge and the block and no dashed line,
hovering the handle adds the line and the arrow, three clicks on pane headers
split nothing, and on a pane titled `sl0ppty` the top handle lands to the right
of the title and left of the buttons -- `drag to move · click to split up` at
x=42, `drag to move` either side of it.

1 files changed, 11 insertions, 3 deletions

diff --git a/docs/panes.md b/docs/panes.md
index 162356b..7e8e745 100644
--- a/docs/panes.md
+++ b/docs/panes.md
@@ -35,9 +35,17 @@ looking at is drawn.
 Every mouse verb starts from the same list of rects the drawing filled in, so
 nothing you click can disagree with what is on screen.
 
-- **Click a pane's border to split toward it** — the side you click is the side
-  the new pane appears on. Resting there first shows a dashed line where the
-  split would land.
+- **Click the middle of a pane's border to split toward it** — the side you click
+  is the side the new pane appears on. Only the middle of an edge splits: three
+  to seven cells of it, called the handle, because a whole edge is a long target
+  to brush past and a changed layout is an expensive accident. Resting anywhere
+  on an edge thickens the handle so you can see where to click; resting *on* the
+  handle adds a dashed line where the split would land and names the direction in
+  the hint bar. The rest of the edge does nothing when clicked.
+- **The top row is the drag handle, and its handle splits upward.** Clicking a
+  pane's header to focus it never splits it. On a titled pane the handle sits
+  wherever the title and the buttons left room, since the title keeps its own
+  cells for the double-click rename.
 - **Drag the gap between panes** to move that boundary. Where two gaps cross,
   drag the crossing to move both at once.
 - **Drag a pane by its title** onto another to swap them. Everything it could