[lstein]

Fixes #433.

Problem

Deleting a directory album left its photomap_index folder (embeddings, UMAP cache, thumbnails, scan bookkeeping) behind inside the user's photo folder. Only InvokeAI-board albums had their derived index directory cleaned up.

Fix

DELETE /delete_album/{key} now removes the album's index directory, under these rules:

• Only folders PhotoMap chose: a directory named photomap_index (the name the album form fills in) or the board album's per-user index dir. Custom index locations and symlinked index folders are left alone. Photos are never touched.
• Shared folders are kept while any remaining album still uses them, compared with os.path.samefile. Comparing path strings misses case-insensitive spellings on macOS and bind mounts.
• Refused (409) while the album is being indexed. The scan, UMAP fit and final save never check the cancel flag, and saving recreates the parent directory, so cancel-and-delete would leave a fresh orphan photomap_index.
• rmtree runs off the event loop, since a thumbnail directory can be large or on a network share.
• An unknown album key now returns 404 instead of a 500 that wrapped the 404.

Frontend: the delete confirmation says the search index is removed too and photos are not touched. A failed delete shows the server's reason via errorDetail(). The utils.js mocks in five Jest suites gained errorDetail accordingly.

Testing

• New tests/backend/test_delete_album_index.py covers: removal; a shared index kept until its last user is deleted; custom location untouched; 409 while indexing; never-indexed album; unknown album 404; a second spelling (symlinked parent) of a shared folder.
• Full backend suite (1358 passed) and Jest (1044 passed); ruff, eslint and prettier are clean.
• An adversarial review found the string-compare and in-flight-indexing problems; both are fixed here.
• Tested manually by the author.

🤖 Generated with Claude Code