Story-2398: keyboard zoom — the keys every reader already has

The founder opened a document, pressed −, pressed =, pressed Shift+= — and nothing moved. Zoom existed, but only under the mouse: the strip's −/+ cluster was the sole way to reach it. Every reader a lawyer has ever used (Preview, Acrobat, Chrome's own PDF pane) answers those three keys, so their silence read as a broken viewer rather than as a missing feature.

The Reading Room's key map now owns them: − zooms out one step, = and + (Shift+=) zoom in one step, 0 returns to Fit.

The steps are the buttons' steps — because they are the buttons' handlers

The one way a key and a button can drift apart is by having two code paths. They do not have two. The shell already owned the zoom (it is a per-document, fit-relative preference in the persisted store — Story-2367, Bug-2356), and it already handed the strip three verbs. The key binder is handed the same three:

src/components/documents/viewer/document-permalink-shell.tsx

const zoomIn  = useCallback(() => zoomBy(ZOOM_STEP), [zoomBy]);
const zoomOut = useCallback(() => zoomBy(-ZOOM_STEP), [zoomBy]);

useZoomKeys({
  enabled: lens === "original",   // only the lens that HAS paper
  onZoomIn: zoomIn,
  onZoomOut: zoomOut,
  onZoomFit: zoomFit,
});

// ...and the strip is given the very same three:
paging={ lens === "original" ? { …, onZoomIn: zoomIn, onZoomOut: zoomOut, onZoomFit: zoomFit } : undefined }

So a press of + and a click of + step by the same ZOOM_STEP (10 fit-relative percent), clamp at the same ZOOM_MIN/ZOOM_MAX (50 / 400), read the same live base out of the store, and write the same per-document entry. There is no second step size to keep in sync, because there is no second implementation.

Where each key is bound, and why

All four sets are declared in one map (readingKeyIntent), even though three different hooks act on it. That is deliberate and predates this Story: the shortcuts overlay reads the map, so a key declared anywhere else is a key counsel is never told about. The two hooks bound on the same window skip each other's intents, so one press never fires twice — the scroll column ignores zoom / zoom-fit / toggle-focus, and the zoom binder ignores everything else.

The guards, unchanged and inherited

The chord guard is structural, not a special case: readingKeyIntent returns null for any metaKey/ctrlKey/altKey press before it looks at the key. Shift is deliberately not in that list — it has to reach through, because + IS Shift+= (and ? is Shift+/, which is how the overlay opens).

Both = and + zoom in: = is the unshifted key the + is printed on, so counsel who does not reach for Shift still zooms in — and counsel who does gets the key the label promised.

The overlay lists them, automatically

The registry is the single declaration the ? overlay reads. Two rows were added to the Reading Room's View group, and that is the entire overlay change — no overlay component, story, or fixture was touched:

src/components/shortcuts/shortcut-registry.ts

{
  id: "view",
  bindings: [
    { id: "focus",   keys: ["F"] },
    { id: "zoom",    keys: ["−", "+"] },   // Story-2398
    { id: "zoomFit", keys: ["0"] },
  ],
},

The glyphs are what a reader expects on a cheat sheet, not the raw event.keys the map matches: the row reads − + because + is what the key is printed with. Copy landed in both locales (Shortcuts.readingRoom.actions.zoom, .zoomFit) — the registry test asserts every named key exists in en AND hi, so a one-locale row fails CI rather than rendering a raw message key at the one moment counsel asked for help.

Verification

Storybook: Shortcuts/ShortcutsOverlay → Reading Room (registry map) is a READ of the registry, so the two new View rows appear there with no story edit. (Keyboard binding itself is shell state, not a component prop — it is proven by the hook tests above, not by a story.)