Rebased onto the consolidated #9475, which now contains #9434 as well — so this branch picks up
#9434's thumbnail-gated preload, its error-path overlay clear and its onInvocationComplete
coverage. This PR's own work is unchanged at ~690 lines in / 690 out: the item-owned state machine,
media-gated reveals, and the bounded output refetch.

Two test adjustments came with the merge, both in the wiring tests:

• CurrentVideoPreview.test.ts gains the assertion that the reveal is actually connected to
  $isTemporarilyShowingSelectedImage. An adversarial review of the fix(ui): viewer progress-image handoff: slow reveal, overlay stuck after socket drop, stale-image flash on quick re-generate #9434 merge found that nothing
  covered it — replacing that wiring with a no-op left all 26 wiring assertions and the full suite
  green with the reveal dead. On this branch the machine is built once in context.tsx for both
  previews, so the check lives there and is made once.
• CurrentImagePreview.test.ts arrived from the merge still describing the controller this branch
  replaces, and is rewritten against the machine: sync, the item-named readiness, attach, and
  negative assertions that none of the three superseded implementations survive beside it.

Ready for review after #9475.

Both confirmed and fixed in a21dec2 — thank you, both were real.

Grace timer vs. slow render. Exactly as you described: the deadline was anchored to the selection, so a slow DTO/render meant the timeout lifted the overlay onto stale or blank content, and the reveal was already spent when the item finally arrived. I took your suggestion: awaiting-media now enters with no timer, and the grace is armed the first time the component actually renders the claimed item without a painted frame — so it bounds only the wait it was designed for (failed loads, undecodable codecs). Until the item renders, the claim just stays outstanding; it's still cancelled by any newer selection (every transition clears the timer) or by the overlay going away. Your test is in as does not run the grace against an item that has not rendered yet: item renders long after the deadline would have expired, and the reveal still occurs.

One deliberate wrinkle: the armed timer is not cancelled if a later sync disagrees on renderedItemName — during an image↔video swap both previews are briefly mounted and sync alternately, and the stale component must not kill the deadline the matching one armed.

selectionChanged as a pick. Also as described. The listener alone can't fully separate the two gestures — ctrl-clicking a off [a, b] and plain-clicking b to collapse the selection produce byte-identical actions and state transitions — so I separated them where the gesture is known, per your suggestion: plain clicks in the grid now dispatch imageSelected (reducer-equivalent for a single name), and selectionChanged is a pure multi-selection mutation that the listener no longer matches. A mutation that moves the active item (ctrl-click adding an item, shift-range) is still published by the change-of-active-item clause; one that leaves it in place (your ctrl-deselect case) no longer bumps the generation. Your test is in verbatim: seed [a, b], dispatch [b], generation unchanged.

Both new tests were verified to fail against the code they fix.

One residual worth naming so it doesn't look overlooked: ctrl-clicking the active item off a multi-selection ([a, b] with b active, ctrl-click b) still reveals — the active item moves to a, so the change-of-active-item clause publishes it. That's unchanged from before this round, and I've left it: the viewer's displayed item genuinely changes there, so showing the user what's now active seems right — but the deselect branch does know the gesture, so if you'd rather suppress that one too it's a small follow-up.

Both confirmed. Fixed, though the delete-flow one took two passes and the second finding sent me
down a hole I've since backed out of — details below.

Delete-pruning dispatches a pick it doesn't mean

Real, and it traces exactly as you described: selection [a, b] with b displayed, hover-delete
a, the survivor branch dispatches imageSelected(b), the listener matches the pick clause, and
because b is already rendered and painted the machine runs awaiting-media → revealing inside
the same sync, so the overlay comes off for the full 2 s.

The first fix used the round-1 vocabulary rather than a new mechanism: that branch prunes a
multi-selection, so it dispatches the mutation action. An adversarial pass then showed that was
necessary but not sufficient, because the branch also collapsed the selection onto
lastSelected, which is snapshotted before the request:

selection [a, b], b displayed, hover-delete a; while the request is in flight the user
ctrl-clicks c, so the active item is now c. The delete resolves, the branch collapses to
[b], the active item moves c → b, the change-of-active-item clause publishes it — same 2 s
flash, and their pick of c is silently discarded.

So it now filters the deleted names out of the live selection, falling back to the surviving
displayed item only when everything selected meanwhile was deleted:

const survivors = getState().gallery.selection.filter((name) => !deletedNames.has(name));
dispatch(selectionChanged(survivors.length > 0 ? survivors : [lastSelected]));

Correcting a claim I made in that commit message: this is not behaviour-neutral outside the
race. A selection of three or more where a non-active member is deleted used to lose the surviving
siblings as collateral ([a,b,c] with c displayed, delete a → [c]); it now gives [b,c],
which is what the branch's comment always said it did. There's a test for it now. deleteVideoModal
had the identical branch and got the identical treatment.

Two holes in that branch I did not close, both pre-existing and both now described in the
comments instead of papered over:

1. The fallback fires only when everything in the live selection was deleted, which means
   lastSelected isn't in it — so that write always moves the active item and always reveals. It's
   the one path in the branch that can't honour the rule below.
2. deletedNames only proves lastSelected outlived this request. Two overlapping deletes
   (shift-clicking the trash on a then b — the button doesn't await) can land the fallback on an
   item the other request already removed; the viewer then shows a name that no longer exists, and
   since it never renders, the machine's claim stays outstanding until the generation ends.

The generalisation, and the part I backed out

Sweeping every imageSelected dispatch for "rewrites the selection without the user having asked
for that item" turned up one more writer: the gallery's auto-select probe. What ships here is only
the vocabulary fix — the probe writes selectionChanged, so when it re-runs and lands back on the
item already displayed it no longer announces itself as a pick, and no longer flashes the overlay.

I also tried to fix the underlying behaviour, which is worse than the flash: the probe selects
item_names[0] unconditionally, so clicking the board you are already on (or the tab already
showing — NoBoardBoard and the view tabs dispatch regardless, unlike GalleryBoard and
VirtualBoardItem) throws your selection away. Five attempts, four adversarial reviews, a new
regression every time:

• Guarding the click handlers swallows the click that is the only recovery when the selection is
  empty — reachable after deleting the last item, after showVirtualBoardsChanged(false) (which
  resets the board and clears the selection without dispatching boardIdSelected at all), and after
  the probe's own give-up.
• Skipping when the displayed item is in the fetched list breaks real board switches: a virtual
  date board's args drop board_id and filter on created_date alone, so its list is a superset of
  every board's items that day. Switching to one then reads as a no-op and strands the viewer on the
  previous board's item, cross-board multi-selection and all.
• Short-circuiting the query wait for a cached list removes the only await, so the effect
  completes synchronously inside the dispatch that started it — and its write lands between
  markNextSelectionAutoSwitched() and the auto-switch's imageSelected, eating the marker, so the
  auto-switch registers as a user pick and flashes the finished image over the next generation. Only
  an incidental cache invalidation keeps that from firing today.
• Skipping when the selection is merely non-empty leaves it stale (a search term narrows the
  list without starting a probe) and, worse, let a no-op click fall through into a wait nothing
  would wake, so the 5 s give-up cleared the selection outright.

None of that is what you flagged and all of it predates this PR, so I've pulled it out to #9535
rather than keep churning an unrelated listener inside a PR under review. That issue carries the
repros and the four dead ends, plus a second pre-existing defect I hit on the way: with the
item-name list already cached and no other action dispatched, condition() never re-evaluates — it
wakes on a dispatch, never on its own timer — so the probe's 5 s deadline expires and clears a
perfectly good selection.

The rule itself is written into gallerySelectionSource's doc comment, including the half my first
attempt missed: choosing selectionChanged is necessary but not sufficient — such a writer must
also leave the active item where it is, and the comment names the two places that can't.

Same-name video src refresh

Confirmed real, and left alone — flagging why in case you disagree. It predates this PR:
usePaintedItemName and its name-keyed readiness are already on main from #9475, and this PR
touches neither. Reaching it needs notifyMediaCookieRefreshed() to fire (the only thing that
changes videoUrl for an unchanged videoName) while that video stays selected, then a
re-selection of it during a live generation; the cost is a blank element under the overlay for at
most the reveal duration, self-recovering. Your suggested shape is the right one — key readiness on
the resolved media URL rather than the name — and I'd rather do that against main than widen this
PR. Happy to file it too, or to fold it in here if you'd prefer it not ship separately.

Tests

Both delete suites now assert every selection write and its whole payload, not just the first.
That mattered: an earlier round of these assertions passed against a survivor branch that pruned
nothing at all, and against one that appended a second, garbage write — which is what the user would
actually have ended up looking at. New coverage for the in-flight-selection race in both modals, the
video modal's fallback (untested before, so removing it silently reintroduced the #9163 empty-viewer
bug), and the three-item multi-selection. Every new assertion was checked by reverting or mutating
its fix and confirming it fails.

Full frontend suite green (1990 tests), types/lint/prettier clean.

LGTM!

OMG, thank you! It's been a long road.