Story-2367: fit-relative zoom — 100% is the reading column

A typed PDF opened at "126%". A scan of the same filing, at the same reading width, opened at "88%". Both numbers were true, and both were useless: the raw pdf.js scale is a percentage of the page's self-declared size, and a scan declares the size of the photograph (a ~1654pt-wide page), not of the paper (595pt). The strip was publishing a fact about the file's box to a lawyer who was asking a question about their reading.

Zoom is now fit-relative everywhere a person can see it, step it, or the app can remember it: Fit == 100% of the reading column, for every document. Two documents at "120%" render the same column width — by construction, not by coincidence.

Where the unit lives (and where it does not)

The raw pdf.js scale did not go away — it got demoted. It now exists in exactly one expression, inside the one component that knows both halves of the division (the live frame, and the page's own width), and it leaves that component only as pixels on paper:

src/components/documents/viewer/reading-presentation.ts

export function fitWidthScale(availableWidth, pageWidth) {
  if (!(availableWidth > 0) || !(pageWidth > 0)) return 1;
  return Math.min(availableWidth, MAX_READING_WIDTH) / pageWidth;   // raw. internal.
}

export function readingScale(availableWidth, pageWidth, zoomPercent) {
  return fitWidthScale(availableWidth, pageWidth) * (zoomPercent / 100);
}

At zoomPercent = 100 the paper is pageWidth × (column / pageWidth) — the column, exactly, whatever the page claims to be. pageWidth cancels. That cancellation is the story: it is why a scan and a born-digital filing at the same displayed percent are the same width, and why 100% can never overflow the right edge.

The clamps moved with the unit. ZOOM_MIN / ZOOM_MAX / ZOOM_STEP are now 50 / 400 / 10, and they mean what they say: half the column, four times the column, a tenth at a time. The old ZOOM_MIN = 10 existed only because a scan's raw fit (~45%, or ~25% on a laptop once the gutters take their 536px) had to be expressible in the same range as counsel's choices. It does not any more — a raw fit is never shown, never stored, and never clamped.

The fit is also exact now, not floored to an integer percent. Flooring made two documents at the same displayed zoom render a few pixels apart, which is precisely the equality this Story exists to guarantee.

Bug-2366 rode along, and the fix is a deletion

Bug-2366 (same PR): in Fit, a window resize flipped the indicator to "88%" and left {"mode":"explicit","percent":88} in localStorage — a zoom counsel never chose, poisoning the per-document memory PR #601 had just built.

What survives is a single invariant, and it is now structural rather than disciplinary: setViewerZoom has exactly two callers, and both are user actions — the −/+ handler and the Fit control.

Migration: the old numbers are DROPPED, not converted

The store goes to v4. Every zoom schema so far has been in a unit v4 does not speak, and neither is convertible where the conversion would have to happen:

A stored 88 meant "88% of a scan's photo size" — which is a zoom counsel had zoomed in to. Reading it as fit-relative would silently shrink their paper to 88% of the column. Converting it needs the page width and the frame width, and migrate() runs at rehydrate, where neither exists. So the entries go. The cost is one forgotten zoom per document; the document reopens at Fit, which is the default it would have had anyway, and one −/+ press restores it in a unit that will still mean something tomorrow.

What counsel sees

The indicator is still the Fit control: in explicit mode it shows the chosen percent and hands the paper back to Fit when pressed; in Fit it rests, because there is nothing to return to. The word "Fit" is gone from the strip — and with it the now-dead DocumentViewer.nav.fit key, removed from both en and hi. "100%" is not a shorter way of saying "Fit"; it is the sentence that was missing.

Verification

The regression guard drives the real DocumentScrollColumn — the component that owns the ResizeObserver, and therefore the only place a re-fit could ever have written itself back — with a stubbed observer and a stubbed frame width (document-scroll-column.test.tsx):

Storybook: Documents/Viewer/ScrollColumn → ZoomModesAndResize and ScannedFilingFitsTheFrame both carry the frame-width control (1280 / 1000 / 780). Drive them side by side: the indicator does not move on resize, and the scan and the born-digital filing are the same width at the same percent. Documents/Viewer/DocumentStrip → ZoomFitMode shows the indicator at 100%.

Typed-%: the strip has no typed zoom input today — the indicator is the Fit control. There was nothing to convert. When one is added, it reads and writes this same fit-relative unit, because there is no other unit left in the viewer above the scroll column.