fix: fill the gallery in as thumbnails arrive

[rvanbaalen]

Closes #132

What changed

Thumbnails reach their cards one at a time instead of all at the end. renderThumbnails hands each finished image straight to the gallery, so the skeleton gives way the moment the first card has something to show, and a large library fills in as it goes rather than staying grey until the last image is done. A card that has not had its turn yet keeps shimmering in place, so an unfinished card never claims to have no preview.

What the gallery watches is no longer total render time but movement. An idle wait of ten seconds restarts on every arrival, so a library of any size is safe as long as something keeps landing, and a run that delivers nothing at all for ten seconds is given up on. A run given up on has its event stream closed, which cancels the renderer, and renderThumbnails checks for cancellation between jobs. Every colour scheme change, preset change and retry therefore stops the run it replaces instead of racing it.

An image the app cannot read is reported as a skipped job naming its preset, rather than dropped in silence. Skips count as movement, so a library whose source folder has moved or been evicted finishes normally and keeps its cards, each drawing the framed glyph GalleryCardView already had for a missing thumbnail. Only a run that stops moving raises the banner, which reads Previews stopped loading. Your wallpapers are all still here. with a Try again button and a dismiss control beside it. The grid stays underneath either way, so the library is still searchable, applicable and editable, and an empty library keeps its own separate empty state.

Trouble reaches os.Logger under the gallery category, following WallpaperManager: unreadable images are an expected condition and log at info, a stalled run logs at error. Nothing technical reaches the user.

Whatever the render does, the gallery leaves the skeleton. A main actor that stops running work altogether stops the watchdog with it, and that remains out of reach from inside the app.

Where the rules live

SpreadPaper/Views/GalleryLoading.swift holds the renderer, the run outcomes, the idle wait, the per-card pending rule and ThumbnailRun.consume, which drives one run and decides when it has stopped. The view builds the jobs, settles each card under its run id, and reads the phase off the outcome. CLAUDE.md gains the file.

The idle watchdog is covered directly rather than through a table of hand-written outcomes: a stream that never delivers and one that stops part way both have to return a stalled outcome under a time limit, a stream fed slower than one idle wait has to come back delivered, and a watchdog that fires last against a run which already reported every job has to come back delivered too. Cancellation is covered against the renderer itself.