feat: an open box zoom draws the frame the release will apply

The controller has always tracked its selection; nothing drew it, so a Ctrl or
Shift drag framed a range with no feedback until the release.

The preview is the area the release will change, not what the pointer swept:
Ctrl frames the x range only, so a band across the plot is what it will zoom,
where the sliver a straight horizontal drag sweeps is only the gesture. The
plot carries the rect a host hands it -- it learns nothing about pointers --
and the renderer draws a low-alpha fill under a light border over everything
else inside the axes.

README.md

@@ -81,7 +81,10 @@ run touched a GPU, so read it as an upper bound and a record of the software pat
 - input parity across hosts: pinch-zoom and pan gestures on Qt6 and GTK4 drive the same
   controller paths as mouse and wheel (touch parity), with keyboard panning
   (arrow keys), Escape cancelling a drag or box-zoom, double-click re-fitting the axes,
-  and modifier-masked box zoom (Shift = both axes, Ctrl = x only, Alt = y only);
+  and modifier-masked box zoom (Shift = both axes, Ctrl = x only, Alt = y only), the area being
+  chosen framed as the drag runs -- a low-alpha fill under a light border, widened along the axis
+  the release will *not* zoom, so Ctrl's frame is the band it is about to apply rather than the
+  sliver a straight horizontal drag sweeps;
 - DPI-consistent sizing: metrics are logical units converted once through
   `Style::ui_scale`;
 - an anti-aliased embedded monospaced font, plus an optional runtime TrueType backend