fix(preview): stamp the window's anchor, not the row the cursor is on

[lstein]

Reveal an image from the image map that sits deeper than the base window can reach — board index ≥ 600 — and Preview anchors its navigation window at that image's page, ~1800 rows down the board. From there, two things went wrong that the grid does not do: today's generations were date-sorted on top of that slice, so the arrows walked onto images the grid was not showing; and stepping onto one filed a brand-new image under board page 30.

The constraint that decides the design

An anchored infinite window is one-way by design: it cannot grow upward past its anchor, because the grid shares the cache entry and rows spliced in above its viewport would shift the content under the user (getPreviousPageParam in gallery/data/queries.ts). Every earlier version of this PR was a way of fighting that constraint, and each one traded the bug it fixed for a worse one.

The fix

The page stamped on a selection is, for an infinite window, the anchor of the window that holds it. That is already what a grid click stamps — the grid's own page, whatever row was clicked. Preview stamped the row instead, and held the stamp sticky per query identity to keep the window from following the cursor. Both halves were wrong: read live, a row-stamped page rolls the window forward at every page boundary and strands everything behind it; held sticky, the anchor ignores a grid click on the newest image at the top of the board and keeps querying rows 1800+ for a selection at row 0.

Stamping the anchor removes the need for stickiness. Preview's own steps never change the stamp, so it can be read live, and the only things that change it are selections made elsewhere — each of which names the window holding the new selection. Nothing is ever released, because the stamp is the selection's window and changes with the selection.

That invariant holds only if every writer of the stamp names the window the item was selected in. Three did not — they selected without a page, which the reducer fills from the grid's page. Once the grid's anchor had been released (a result landing on the board does that; so does a reload) while Preview's had not, a deletion successor chosen from Preview's own list, "open in preview" from Preview's own menu, and the retained multi-selection after a partial delete were all filed at page 0, outside the window they came from. The action context Preview hands to image actions now carries Preview's own stamp, and those selections use it. Hosts that provide no page keep the exact call they made before.

Two smaller consequences follow: an item the window does not hold — a local recent, or the compare slot's image — is stamped at the top of the listing; and swapping the compare image back out restores the page the item was selected at rather than guessing, so a swap round-trips to a working state. That memo is honoured only in the query it was recorded in — a page names a window of one listing, and restored into another board's query it would anchor that listing 1800 rows down around an image that is not in it.

What earlier versions got wrong, so it isn't repeated

Six rounds of adversarial review rejected five designs and two incomplete ones. Keying the recents guard off the stamped page hid a just-generated batch from Preview the instant it settled. Keying it off the grid's live page suppressed recents for a selection on a different board. Releasing the stamp whenever the grid released its anchor orphaned a deep selection outside its own window. Stamping the top of the listing for any item the window didn't hold collapsed a deep window to row 0 on the first arrow press across a page boundary. And the anchor design itself was incomplete until every page-less writer of the stamp was found.

The common thread: each treated the stamp as something to be corrected from outside, when it is the selection's own window and only a selection may change it.

Scope

Frontend only. The preview hook and view, the action context Preview provides to image actions (one optional method), the multi-selection reducer and command (one optional page), and their tests. No persistence changes.

One recorded behaviour change outside the deep-window case: a paginated boundary crossing now stamps the page landed on rather than the one departed from. On main the continuation looked the item up in data it did not have and fell back to the departed page; the sticky anchor hid it in-session and it only showed on remount.

Testing

pnpm run lint (format, oxlint, typecheck, architecture check), 6,686 unit tests, 910 browser tests and the architecture suite pass. Fifteen new cases, each verified to fail against exactly the behaviour it replaces and against nothing else: recents excluded from a deep window (infinite, and with a stamp that outlives a switch to paginated mode); an in-flight image and the compare image stamped at the top; the window holding still across a page boundary and back; Preview moving to the top when a selection is made there from outside it; the action context's page for an item in the window and for a recent; the compare swap round trip, and the memo declining to fire for another item or in another listing; the window anchor handed out for an item on a later page of the window; the successor and the retained multi-selection carrying the host's page; and the reducer stamping an explicit page into the navigation query already on the selection rather than rebuilding it from a grid that has since moved to another board and search.

The harness needed corrections that explain why none of this had coverage: the galleryItemsInfiniteOptions mock discarded an infinite window's offset; its getPreviousPageParam let an anchored window page upward past its anchor; a re-render built a fresh QueryClient, discarding exactly the cached pages a window change has to survive; and the selection command being a mock meant a second arrow press still started from the item the first one left.