fix: refresh the slideshow in place after index updates; surface pre-scan indexing failures

[lstein]

Summary

Two related fixes to the index-update experience, verified live by the author.

1. The slideshow now refreshes in place after an index update

After an index update completed (the semantic map's reindex button from #344, or Album Management's Update Index), the UMAP reloaded but the swiper/grid kept their stale image count and slides — new images were unreachable without a full page reload. The Album Manager path additionally reset the user to slide 0 and cleared any active search.

Both completion paths now dispatch albumChanged with a new changeType: "refresh" carrying the fresh filename_count, meaning "same album, image set changed in place":

• slide-state.js keeps the current position and active search results, clamped against the new total. Index updates append, so existing indices only shift when images were removed; search hits that now point past the end are dropped, and search mode exits only if none survive.
• swiper/grid rebuild through their existing albumChanged listeners; the grid bumps its thumbnail cache-breaker.
• umap.js ignores the refresh event (the map reloads via albumIndexUpdated) — this also removes the old quirk where an Album Manager update of the current album forced the map window fullscreen via initializeUmapWindow. The albumIndexUpdated listener now fetches immediately only while the window is visible; otherwise it marks the data stale for the next open.
• bookmarks / back-stack keep their in-memory state instead of treating the refresh as an album switch (the back-stack drops only entries pointing past the new end).
• The Album Manager's old direct resetAllSlides() call (which rebuilt against the stale count) is removed; the refresh event does it once, correctly.

2. Index progress can no longer get stuck on "No operation in progress (0/0)"

Updating an InvokeAI board album could leave the album card polling that idle status forever. Root cause was two gaps:

• The background task only registered with the progress tracker after the InvokeAI board fetch and the existing-.npz load, so polls during that window saw no operation at all (for a large album the npz load alone is seconds of "idle").
• progress_tracker.set_error() silently dropped errors when no tracker entry existed — a failure before scanning started (e.g. a misconfigured/unreachable InvokeAI on the first update after a server restart) was logged server-side but invisible in the UI, permanently.

Fixes: the update_index_async endpoint registers the operation before scheduling the background task (which also closes a double-start race — is_running is true from the moment of the POST), the board fetch and index load report progress steps ("Fetching board contents from InvokeAI...", "Loading existing index..."), and set_error creates the entry it needs. A previously-invisible InvokeAI 404 misconfiguration was surfaced by this fix during live testing.

Tests

• tests/frontend/slide-state-refresh.test.js (new): position/search preservation, clamping, dropped out-of-range hits, plain album switch still resets.
• umap-reindex.test.js: completion dispatches the refresh event with the fresh count.
• album-manager-progress.test.js: completion fires albumIndexUpdated + refresh for the current album only.
• test_progress.py: set_error with no prior entry creates a visible ERROR entry.
• test_invokeai_board_index.py: pre-scan failure with an empty tracker (fresh server) surfaces as "error" instead of hanging.
• test_index.py: the endpoint registers progress before the task runs.

All suites pass: 455 backend, 411 frontend (+7 new), ruff, eslint, prettier.

🤖 Generated with Claude Code