Rail ticks sit at observation INSTANTS while chart bars sit at period START (up to 0.61 day apart)

[HichemMokni]

Residual after #57

The scale error is gone. Measured on the deployed build (eeb7406), rail label centre vs
the bar centre for the same date:

	before #55/#57	now
un-zoomed max	190.3 px	1.33 px
un-zoomed mean	110.12 px	0.90 px
zoomed max	50.0 px	5.52 px
zoomed mean	25.15 px	5.51 px

What remains under zoom is a constant offset, not a scale error: every sampled label is
5.51 px to the right of its bar — mean equals max to two decimals. Un-zoomed the same
measurement gives 0.90 px.

Why it is not simply my measurement

The labels are all 5 characters (MM-DD), so a text-centring artifact would produce the
SAME constant in both states. It does not: 0.90 un-zoomed vs 5.51 zoomed. Something in the
zoomed path contributes a fixed shift.

Both published halves look correct in that state: the band is [431, 1821] (matches the
plot rect exactly) and the domain is [2025-08-30, 2026-01-31], which is post-.nice() as
intended.

Worth checking when picking this up

• Effect ordering: the domain is published in a layout effect while doZoom re-positions
  the bars in a passive effect, so within one commit the rail can lay out against a
  domain the bars have not yet been re-x'd for. Un-zoomed the bars are positioned during
  render instead, which would explain why the residual appears only under zoom.
• Whether .nice() applied to a zoomed scale shifts the origin in a way the rail then
  reproduces faithfully while the bars are drawn from the pre-nice zoom transform.

Low priority: 5.5 px on a 1390 px band is ~0.4%, and the reported symptom (drift growing
across the axis, up to 190 px) is resolved.

[HichemMokni]

CORRECTION — my "constant translation" framing was wrong, and so is the half-bar-width theory

Re-measured across five zoom depths. The offset is not constant; it grows with zoom. But
expressed in TIME rather than pixels it is dead constant, and it takes exactly two values:

visible span	px/day	min offset	max offset
638 d	2.18	0.096 d = 2.31 h	0.610 d = 14.65 h
274 d	5.07	0.103 d = 2.46 h	0.611 d = 14.67 h
98 d	14.18	0.104 d = 2.49 h	0.611 d = 14.67 h
33 d	42.12	0.104 d = 2.51 h	0.612 d = 14.68 h
12 d	115.83	0.105 d = 2.51 h	0.612 d = 14.70 h

Those two numbers are the AOI's two Sentinel-1 pass times: 02:30Z descending and
14:32-14:41Z ascending.

Root cause: the rail marks INSTANTS, the chart marks PERIODS

The rail places each tick at the true observation instant, which carries a time of day. The
chart's bars are daily and sit at the period START (midnight). So a tick for a 14:40 pass
genuinely belongs 61% of the way through its own day — it is not misplaced, it is measuring
a different quantity. Since the bar is drawn 0.7 x the gap wide and centred on midnight,
it covers only midnight +/- 0.35 d, so a 0.61 d tick falls OUTSIDE its own bar and reads as
"shifted".

This is the same period-vs-instant distinction as #50, now on the rail
instead of the click path.

Refuting half-a-bar-width (guardian's Q1)

A rendering offset of width/2 would produce one value; the measurement shows two
tight clusters. In days a half-bar would be a constant 0.35 d at every zoom; measured are
0.104 d and 0.612 d, matching the two pass times to within a minute across a 50x zoom range.
It also would not split by pass direction, which this does exactly.

Suggested fix

Place the rail tick by the SAME containment mapping already used for the selected-time
marker — columnForInstant from lib/Charts/barColumnSnap.ts (#50) — so a tick sits on the
bar for the period that contains its instant, and the marker and the rail agree by
construction rather than by coincidence. The instant stays the tick's identity for
click/stepper purposes.

Known cost, worth stating before anyone implements it: the 4 two-pass days would render
two ticks at the same x. Exact-instant identity still distinguishes them for the stepper, but
they would visually overlap.