Never file a render under a frame it did not come from

[seanharding]

#800 stopped a finished render being attributed to whatever frame was selected, but only closed half the hole: it checked whether the render's source_hash matched an open asset and, on a miss, still fell back to selected_file_idx. That fallback fires whenever the list has moved on -- a different folder opened, or a merge swapping frames for a composite -- and _update_thumbnail_from_state runs on file switch, on save and after an export, not only from the render that produced the buffer. So last_metrics can hold a render whose frame is no longer open, and its picture is filed under whichever frame is selected now. The write is persisted, so it outlives the session and stays wrong until that frame is rendered again.

Found on disk rather than reasoned about: an audit of 68 raw files under one shoot compared every cached thumbnail against its own file by structural correlation, robust to a rendered positive differing in tone from the source preview. One frame scored 0.10 -- slide-07's beach sunset carrying a sideways slide-09-style render -- and the mis-filed image matched, at 1.00, the thumbnail legitimately owned by a frame in slide-08. One image, two keys.

A render that cannot be attributed to an open frame now updates nothing. The cost is a skipped refresh in exactly the case where the alternative is writing someone else's picture; the next render of that frame fills it in.

The no-source_hash fallback goes too. It was justified on the grounds that active_file_changing snapshots the outgoing frame, which is still selected -- but that cannot be told apart from a different folder being open now, which is the failure above. The render worker sets source_hash unconditionally on a required task field, so refusing costs nothing real.

Three existing fixtures omitted source_hash and leaned on the fallback to attribute; they now set the hash their asset carries, which is what the worker always does.