Gallery auto-select probe: no-op navigation discards the selection; quiet store clears it

The gallery's auto-select probe (`app/store/middleware/listenerMiddleware/listeners/boardIdSelected.ts`) exists to give the viewer something to show after a board or view change. It has three defects that are independent of each other but share a root: it treats every `boardIdSelected` / `galleryViewChanged` as a real navigation, and it depends on a `condition()` wait that can expire without ever being evaluated.

All of these reproduce on `main`. I found them while reviewing #9520 and attempted a fix there; every attempt introduced a worse regression, so I pulled it out into this issue rather than keep iterating inside an unrelated PR.

### 1. Navigation that changes nothing throws away your selection

`NoBoardBoard` dispatches `boardIdSelected({ boardId: 'none' })` whether or not that board is already selected, and `GalleryPanel`'s Images/Assets tabs dispatch `galleryViewChanged` on every click. `GalleryBoard` and `VirtualBoardItem` both guard against this; those two don't.

The probe re-runs and selects `item_names[0]` unconditionally.

1. Open Uncategorized, scroll down, click an older image.
2. Click **Uncategorized** in the boards list (the board you are already on), or the **Images** tab while it is already showing.
3. The selection jumps to the newest item.

With a generation running it also moves the displayed item, which the viewer reads as a change worth revealing, so the progress overlay lifts for a couple of seconds.

### 2. A quiet store turns a board switch into a cleared selection

`condition(predicate, 5000)` only re-evaluates its predicate when an action is dispatched — never on its own timer. So when `listGalleryItemNames` is *already* fulfilled for the new args and nothing else dispatches, the probe never wakes, the 5 s deadline expires, and the give-up branch dispatches an empty selection.

1. Visit a board so its item-name list is cached.
2. Go elsewhere, then come back to it.
3. Don't touch anything for five seconds.
4. The selection is cleared and the viewer drops to its empty state.

Ambient traffic usually masks this — a socket event or a query landing is enough to wake it — which is why it is intermittent rather than constant.

### 3. Uploading to the board and view you are already on selects nothing

`imageUploaded` / `videoUploaded` dispatch `boardIdSelected({ boardId })` then `galleryViewChanged('assets')`. When both already match the current state, the second cancels the first's probe (`cancelActiveListeners()` runs before the effect decides it has nothing to do), and neither selects the upload.

### Why the obvious fixes don't work

Recording these because each looked right and each broke something:

- **Guarding the click handlers** (adding the `selectedBoardId !== …` check `GalleryBoard` has) swallows the click that is the only way to recover 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 defect 2 above.
- **Skipping when the displayed item is already in the fetched list** breaks real board switches: a virtual date board's query args drop `board_id` and filter on `created_date` alone, so its list is a superset of every board's items for that day. Switching from a real board to a date board then looks like a no-op and strands the viewer on the previous board's item, with a cross-board multi-selection surviving the switch.
- **Short-circuiting the wait when the list is already cached** (`selectQuery(getState()).isSuccess || await condition(...)`) removes the only await, so the effect completes synchronously inside the dispatch that started it. Its write then lands between `markNextSelectionAutoSwitched()` and the auto-switch's own `imageSelected`, consuming the marker — so the auto-switch registers as a user pick and flashes the finished image over the next generation. Today an unrelated cache invalidation happens to mask it.
- **Skipping when the selection is merely non-empty** leaves the selection stale: a search term (and any other arg change) narrows the list without starting a probe, so the selection can be non-empty and absent from what the grid shows, and the click that would fix it gets swallowed.

A fix probably wants to decide "did this navigation change anything?" from the pre-action state *and* keep a way to recover when the current selection isn't in the list on screen, while leaving the query wait's timing alone. Defect 2 is worth fixing on its own first, since several of the above interact with it.