Low priority: image map hover thumbnail can reappear at stale coordinates #9634

Priority: low. Cosmetic, self-correcting, and needs an unusual sequence to trigger. Filed for the record rather than as something worth scheduling.

What happens

The image map's hover thumbnail is hidden when its image is no longer in the point set — derived at render in ImageMapPlot.tsx, so a live refresh does not cancel hovers that are still valid. The underlying pendingHoverPreview state is kept, though, and nothing retires it.

Nothing fires plotly_unhover for a point that no longer exists. So if a later refresh restores that image while the pointer has not moved and has not hovered anything else, the derivation stops suppressing the preview and the thumbnail reappears — positioned at the cursor coordinates captured when the hover first began, which may be nowhere near where the pointer is now.

Why it is low

All three conditions have to hold at once:

1. The hovered image leaves the map (a re-projection that drops it).
2. The pointer stays completely still — any plotly_hover or plotly_unhover on any point clears the preview.
3. A later refresh restores that same image.

The result is a misplaced thumbnail. No data is wrong, selection and recentering are unaffected, and it disappears as soon as the pointer moves.

Why it was not fixed with the rest

Both obvious mechanisms are rejected by the project's lint rules:

• Clearing the state from an effect keyed on the derived staleness trips react-compiler/EffectSetState ("Calling setState synchronously within an effect can trigger cascading renders").
• Reading a "retired preview" ref during render to make the suppression permanent trips react-compiler/Refs ("Cannot access refs during render").

Both were tried and backed out. Landing either would have meant a lint suppression in production code, which is not proportionate to a cosmetic tail case.

Closing it properly likely means restructuring the hover state so retirement is expressible without either — for example driving the preview from a small external store owned by the plotly event handlers, rather than from component state. That is a refactor worth doing only if this area is being reworked anyway.

Context

Found by an adversarial review of invoke-ai#41 (feat/image-map-08-live-theme); split out of #9635, which covers an unrelated medium-severity issue in the same runtime. The visible half of the original finding — a stale thumbnail shown for a point that is gone — is fixed on that branch.