sl0ppty: the split arrow belongs on the button

The arrow rode the middle of the dashed boundary line, which put the two halves
of one message in two places: the handle said *press here* and a glyph out in the
middle of the pane said *this is what happens*. It also meant the direction was
unreadable until you were already on the target, since the dashed line is stage
two of the hover.

So the arrow moves into the handle and the boundary line goes back to being a
plain boundary -- which is the honest shape for it anyway: it is the *edge* of the
pane you are about to make, and an edge has no middle worth marking. The handle
is now one object that explains itself, and because the handle is drawn from the
first stage, brushing any part of an edge tells you where its button is and which
way that button splits, without previewing a boundary nobody asked about.

Knocked out with ATTR_INVERSE rather than drawn in a second colour: the bar is
solid `guide`, so a `guide` glyph on top of it would have been invisible, and
inverting gets contrast that follows whatever colour the theme sets for no new
knob. Along the handle the arrow sits in the middle, where the pointer is aiming.
Across it -- a distinction only the upright pair has, being the two that grow a
second cell -- it sits on the edge's own cell rather than the one over the
content, because it marks a boundary and the boundary lands on the frame.

Verified: `make retest`, **1873 checks measured** (`test_split_ux.py` 100 of
them), all green. The test that pinned the arrow to the dashed line is now the
test that pins it to the handle, on all four sides, plus one that it is legible
from the first stage with no boundary drawn.

Checked live on a 116x36 pane: `◄█` at column 2 and `█►` at column 117 on the
middle row of their bars, `━━━███▼███━━━` on the bottom border's single row, and
-- the case that shows why this is worth it -- hovering the *far left* of the top
row draws `███▲███` at column 85, where the handle actually is, having dodged a
centred title.

A note on the two commits before this one: their messages quote 1801 and 1807
checks, which were carried over from earlier in the session rather than measured.
The figure was 1865 at that point. The code and the tests were right; the numbers
in those two messages were not.

1 files changed, 5 insertions, 5 deletions

diff --git a/docs/panes.md b/docs/panes.md
index fc27020..b341821 100644
--- a/docs/panes.md
+++ b/docs/panes.md
@@ -39,11 +39,11 @@ nothing you click can disagree with what is on screen.
   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 fills the handle in solid so you can see where to click — a cell
-  wider on the left and right edges, and no taller on the top and bottom ones,
-  since a row is about twice a column and a two-row bar reads as a wall. 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.
+  on an edge fills the handle in solid, with an arrow in it for the way it will
+  split — a cell wider on the left and right edges, and no taller on the top and
+  bottom ones, since a row is about twice a column and a two-row bar reads as a
+  wall. Resting *on* the handle adds a dashed line where the new boundary will
+  land. 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