sl0p: make the split button visible, and clickable where it is drawn

The `+` shipped in 0.1.7 and 0.1.8 without ever appearing on a live session,
while rendering in 265 snapshots. Four faults, each enough on its own:

- title_line_without_middle computed the right side only inside the left
  side's and_then, so a pane with no title (hide_default_pane_names, the live
  default) got none at all;
- title_line_with_middle discarded the right side whenever the left was
  absent -- that is every frame in a session with a second client, which the
  live box always had, and "MY FOCUS AND:" on every frame was saying so;
- the title was budgeted before the button, so a title longer than the frame
  (any shell showing a path) consumed its columns. The button is anchored and
  hit-tested by pure geometry, so it cannot be the part that loses;
- the click hit-tested position_and_size() while the frame is drawn inset by
  the pane gap, putting the clickable columns two right of the glyph and a row
  above it at the top of the screen. Hence "the click works" and "nothing is
  drawn" both being true, and that click test proving nothing.

Adds Pane::frame_rect(), the rect the frame is really drawn in, which the
status bar buttons had already had to work around by hand.

Also fixes render_my_focus building its short form from separators that
Vec::append had already drained: 4 cells wide while reporting 6, a title line
two cells short of its pane. Found by asserting the width in the new test.

Verification, since unit tests have now been insufficient here four times:
split_button_is_drawn_where_it_is_hit_tested covers the combinations the live
config produces, and packaging/checks/split-button-live.py (make check-live)
reads the glyph off a real session, attaches a second client to force the
middle builder, and clicks the columns it found the glyph in. Both confirmed
to fail on the parent commit.

1 files changed, 31 insertions, 0 deletions

diff --git a/docs/roadmap.md b/docs/roadmap.md
index bc8aa6f..98c8949 100644
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -215,6 +215,37 @@ Two panes sharing one rect means a stack; distinct rects mean it really
 expanded. Check both directions (create narrow then widen, create wide then
 narrow) and add panes afterwards.
 
+## Fixed: the `+` split button was drawn nowhere and clicked in the gap
+
+Shipped in 0.1.7 and 0.1.8 without ever being visible on a live session, while
+rendering in 265 unit snapshots. Four separate faults, each individually enough
+to hide it:
+
+- `title_line_without_middle` computed the right side only if the pane had a
+  title -- and `hide_default_pane_names true` means unnamed panes have none;
+- `title_line_with_middle` dropped the right side whenever the left was absent,
+  which is every frame in a session with a second client (`MY FOCUS AND:`);
+- the title was budgeted before the button, so a title longer than the frame
+  (i.e. any shell showing a path) consumed its columns;
+- the click hit-tested the pane's allocation while the frame is drawn inset by
+  the pane gap, putting the clickable columns two to the right of the glyph.
+
+The first three are fixed in `ui/pane_boundaries_frame.rs` by reserving the
+anchored button before anything else and never discarding the right side; the
+fourth by `Pane::frame_rect()`, the rect the frame is actually drawn in.
+
+**How to re-run the check** -- unit tests were necessary and insufficient here
+for the fourth time, so this one reads the screen:
+
+```bash
+make check-live      # packaging/checks/split-button-live.py
+```
+
+It starts a session at a pty with the live frame config, finds the `+` on the
+frame, attaches a second client (the middle builder), and clicks the columns the
+glyph was found in, expecting `2 -> 3` panes. Confirmed to fail on the commit
+before the fix, for both the render and the click.
+
 ## Standing risks
 
 **`sl0ppij/target` is a symlink to `~/lol/zellij/target`.** Introduced when the