feat: index video files as their extracted still frame

[lstein]

PR 7 of 8 — ⬅ the flip. Stacked on #360.

This is the commit that turns video support on. Everything it activates was merged and tested in #355–#360, which also makes it the single revertible commit that turns it back off.

The walk now defaults to INDEXABLE_EXTENSIONS, and _load_image dispatches videos to a new _load_video returning the same (frame, modtime, metadata) shape. Everything downstream is therefore media-agnostic — a video is CLIP-encoded, clustered, searchable and curatable exactly like a photo.

The gate bypass is the sharpest thing in this PR

_passes_dimension_gate returns early for videos, and that early return is the point rather than an accident of the byte bands:

• the middle band opens the file with PIL, which raises on a video
• the caller memoizes that False into scan_rejects.npz keyed by (size, mtime)
• those only change if the file itself does — so a video rejected once stays invisible forever, with no UI to clear it

And it would not have shown up in manual testing: most real videos exceed the 500 KB probe ceiling and pass on size alone, so this only bites with small clips. scan_rejects.npz gains a cache_version, bumped here, so anyone who ran an intermediate build gets their cache discarded once.

Batch isolation

flush() now retries a failed batch one item at a time. Extracted frames are the first realistic source of a PIL object the encoder chokes on, and losing seven unrelated photos to one bad video would be confusing and hard to attribute.

Cache lifecycle — one sweep, not seven hooks

Stills are swept at save time, when the index is authoritative. That single sweep covers mtime changes, moves, copies, single and batch deletes, and files removed outside the app. Delete also discards immediately (a stale frame for a deleted file is exactly what users notice), and album deletion clears the album's cache.

Reporting

bad_files were collected but surfaced nowhere — users just saw a smaller count than expected. They now become a completion warning, composed with rather than clobbering the board album's missing-on-disk notice (that's what #360's add_completion_warning was for).

Board albums stay image-only: deletion there routes through invokeai_client.delete_image, unverified against video assets, and indexing something we couldn't then delete would be worse than skipping it.

Tests

19 end-to-end in test_video_indexing.py, against a new new_media_album fixture copying test_images/ and test_media/ — so existing suites keep their exact counts and only video tests pay the ffmpeg cost.

The most valuable one: test_cached_frames_are_not_reindexed_as_photos runs the update twice and asserts a stable count. Stills are full-resolution and sail through both gates, so if the cache ever lands inside a scanned tree every still becomes a photo — and each of those gets a still of its own, forever.

Also covers: the truncated file being skipped without aborting, the gate bypass under an absurd min_image_dimension, videos never entering scan_rejects, the stale-cache discard, prune-on-update, delete-removes-frame, UMAP inclusion, and a deterministic self-match search (a video's own frame is its own top result — no claims about CLIP's view of a test pattern).

Backend 609 passed, frontend 501 passed, ruff clean.

🤖 Generated with Claude Code