v3.19.1

fix: the perf overlay was charging its own weight to your terminal

Three defects in the instrumentation itself, found while extending it. Each made the
panel report something untrue, which is the only kind of bug a measuring tool cannot
have — and every one of them was invisible from the outside, because a wrong number
looks exactly like a right one.

- The overlay's own render cost was billed to `flush`. It was excluded from `build` by
  being drawn after it, and the comment said "excluded from every channel above" — but
  the event loop computed `flush = whole_draw - build`, and `whole_draw` wraps the
  overlay. So the panel inflated the exact channel `verdict()` reads to conclude
  "TERMINAL FLUSH - the emulator is the slow part". It now times itself into an
  `overlay` row and a pure `attribute_frame` subtracts it. Measured with the panel open:
  0.09 ms p95, which was going to the emulator's account.

  The residual limit is in the code and stands: the extra cells the panel puts in
  ratatui's diff ARE real work for the emulator. This removes our layout cost, not the
  emulator's cost of drawing us, so a panel-open `flush` is still slightly pessimistic.

- `motion/s` and `event/s` were always the same number. Both counters were incremented
  on adjacent lines inside `if kind == Moved`, so no key, click, wheel, drag or resize
  was ever counted, and `backlog` described only motion coalescing rather than queue
  depth as its own doc claimed. Two rows on screen showing one fact. Every event now
  counts, carried to the next frame so the hot path takes no extra lock. Verified
  through a pty: six keypresses plus a quit now show as 4330 events against 4323
  motions, where before the two totals were identical by construction.

- The `[x]`'s hover highlight was dead. `apply_hover` set the style and the overlay then
  drew `Clear` over the same cells, which resets them - computed, then wiped. This is
  the "clickable but dead on hover" miss CLAUDE.md names by name, in the code that
  quotes the rule. The panel paints its own hover now, which also means the highlight
  cannot lag a frame behind a panel that has moved. The regression test asserts the
  background actually changes, and fails on the old implementation.

Also: the panel is now opaque to the mouse. Only its `[x]` was hit-tested, so a click in
the middle of it selected the repo row behind it and a drag near its edge grabbed the
splitter underneath. Its whole rect is registered, like every other captured geometry.

And the `build`/`palette`/`hover` docs now say those NEST rather than sum — `build`
contains the other two, so a reader adding them up got a number that means nothing.