feat: albums backed by InvokeAI image-gallery boards

[lstein]

Summary

Adds a second album source type: an album can now mirror one or more InvokeAI gallery boards instead of scanning a local directory tree. When creating an album, a radio pair selects between Directory of Image Files (default, unchanged) and An InvokeAI Image Gallery Board.

For board albums, the form takes the InvokeAI backend URL (prefilled from Settings), the locally-accessible InvokeAI root directory (filetree picker — deliberately not fetched via the API), and optional credentials, then loads the board list into a multi-select checklist. Indexing fetches the boards' image names from the InvokeAI API, resolves them to <root>/outputs/images/<name>, and feeds the explicit file list through the existing Embeddings pipeline — so "Update Index" naturally picks up images added to or removed from the boards.

Design decisions

• Deletion goes through the InvokeAI API (DELETE /api/v1/images/i/{name}), never send2trash — deleting files directly would leave dangling rows in InvokeAI's database. move_images is rejected for board albums for the same reason.
• Indexes live in the platformdirs data dir (user_data_dir("photomap")/indexes/<album_key>/embeddings.npz), derived server-side; album keys are sanitized against path traversal, and deleting a board album removes its derived index directory.
• Credentials never reach the browser. Album endpoints expose has_invokeai_password instead of the password; the probe/board-listing endpoints resolve stored passwords server-side and only ever pair a stored password with its own username. The form surfaces this by prefilling the Settings username and noting the saved password will be used (cleared when the URL points at a different backend).
• Source type is immutable after creation (radios disabled on edit) — avoids index/path migration.
• image_paths is derived as [<root>/outputs/images] so image serving and access validation work unchanged; HTTP helpers were extracted from routers/invoke.py into a shared invokeai_client.py so the indexing/curation layers don't import a router.

Robustness fixes found while testing against a live InvokeAI

• The add-form entrance animation clamped the section at 600px (forwards fill), overflowing the taller board form and hiding the Add Album button.
• Progress pollers held the card element captured at kickoff; card rebuilds mid-indexing left the visible card frozen at "Indexing in progress..." while the backend completed. Pollers now re-resolve the live card every tick, and freshly added albums are guarded against a duplicate racing kickoff (which also fixes occasional spurious 409 alerts for directory albums).
• Indexing log lines no longer dump the full resolved file list (thousands of paths for board albums) — long explicit lists are summarized as a count + common parent.
• Unreachable backend / wrong root fail fast with pointed progress errors and never touch an existing index.

Tests

• Backend: board-album CRUD, YAML round-trip, legacy-config compatibility, password-leak guards, probe endpoints incl. credential-pairing rules, and end-to-end indexing / board-membership updates / API-routed deletion / move rejection against a stubbed InvokeAI client.
• Frontend (Jest): source toggle, board checklist, add/edit payload shapes, settings-credential surfacing, animation clamp removal, and poller live-card resolution.
• Verified manually against a real multi-user InvokeAI 5.x instance (2,093 images across 4 boards): connect → board select → index → re-index after board changes → delete-from-PhotoMap reflected in InvokeAI's gallery.

🤖 Generated with Claude Code