fix(adapters): draw linked hover and the edit-drag preview in data units on a log axis

[jvdd]

Three log-axis bugs found in the review of #113. They sit on the same boundary: Plotly holds log axis positions in log10 units, while FlexViz values are data units. The third also affects linear axes.

Change

• Linked hover (plotly/hover.js): guides, bands and rects passed data values to l2p, which expects log10 on a log axis. They now use c2p. In plotly.js 4.1.1 c2p is l2p on every axis except log, where it takes log10 first, so linear, date and category axes keep their old behavior. (d2p was rejected: on a date axis it parses an epoch-ms number through new Date() and shifts it by the browser's timezone offset.)
• Band and cell clipping (plotly/hover.js, axisSpanToPixels): bands and cell outlines are clipped to the plot area. A zoomed grid snaps outward, so its first bin starts left of the plot. On a log axis the lattice puts that edge at 0 whenever the zoom starts below one bin width, and c2p(0) has no position. c2p(v, true) maps it past the axis start, and the clip keeps the band inside the plot. Guide lines keep c2p(v): a guide at or below 0 on a log axis is not drawn.
• Edit-drag preview (plotly/events.js): _fvOutlineDataRange used p2r, which is log10 on a log axis. It now uses p2d on a log axis only, as Plotly's own makeFillRangeItems does. Date and category axes are unchanged.
• Architecture.md: the "Log axes" bullet describes the three fixes.
• Tests: the off-UTC hover band test moved to TestLinkedHoverBrowser. The two edit-drag live brush tests are one test, parametrized on linear and log.

Impact

• On a figure whose x axis is log, a linked hover guide from another figure now lands at the hovered value. Before, it was placed thousands of pixels off.
• On a zoomed log-axis histogram, hovering in the first bin now draws its band. Measured: zoom to 2..500 with bins=50, the first bin is [0, 9.98] and covers 29 % of the plot width. Before this PR the band was drawn at a wrong position; with c2p alone it was not drawn.
• On a zoomed linear-axis histogram, the band of a partly visible edge bin no longer spills over the y-axis labels (measured: 4 px).
• While a user drags an existing box on a log-axis cube source, the live preview now matches what the commit on mouseup shows. Before, the preview used log10 values as data bounds. The committed selection was already right.

Related: #127 (a histogram with a bin edge at 0 on a log x axis autoranges over 16 decades).

Tests

• TestLogAxisBrowser::test_linked_hover_guide_lands_at_the_data_value_on_a_log_target: the expected pixel is computed independently (l2p(log10(x))). Fails before the fix.
• TestLinkedHoverBrowser::test_temporal_hover_band_lands_on_the_bin_edge_off_utc (browser time zone Europe/Brussels): guards the date axis. It fails with a d2p version of the fix.
• TestLinkedHoverBrowser::test_hover_band_is_clipped_to_the_plot_area[linear|log]: the band starts at the plot edge and ends at the bin edge. Fails before the fix (linear: band at 56.16 px, plot at 60 px; log: no band).
• test_browser_cube.py::TestLiveBrushCube::test_edit_existing_box_live_brush[linear|log]: the live preview equals the committed result at the same mouse position. The log case fails before the fix.
• Tree merged with main, pytest tests flexviz_polars/tests: 2425 passed, 2 skipped.
• Tree merged with main, pytest -m browser tests: 339 passed, 15 skipped.

[codspeed]

Merging this PR will not alter performance

✅ 31 untouched benchmarks

---

_{Comparing fix/log-axis-hover-and-edit-brush (9d9a618) with main (a82504e)}