fix: surface actionable delete-failure messages instead of a bare HTTP 500

[lstein]

Summary

Deleting an image the server can't remove (e.g. a read-only folder) popped a dialog reading:

Failed to delete: HTTP 500 Internal Server Error for delete_image/family/4425?move_to_trash=true

Two failures stacked: the backend wrapped the PermissionError in a generic 500, and the frontend showed HttpError.message while the server's explanation sat unread in error.body.detail. This fixes both halves.

Changes

Backend (routers/index.py)

• New _remove_image_file() helper wraps the trash/unlink step of delete_image and translates OS failures into HTTP errors whose detail tells the user what to fix:
  • PermissionError → 403 — "Cannot delete 'img.jpg': permission denied. The PhotoMap server needs write permission on the image file and its containing folder."
  • send2trash's TrashPermissionError → 403 — the file may be deletable even though the trash folder isn't usable, so the message suggests switching "When deleting" to "Just Delete" in Settings.
  • Other OSError → 500, but the detail now carries the OS reason (e.g. "Invalid cross-device link" from the known no-trash-dir-on-mount case) plus the same Settings hint when trashing was what failed.

Frontend

• New errorDetail(error) helper in utils.js prefers the server's {detail: "..."} string over the generic HTTP <status> for <url> message (string details only — FastAPI validation lists fall back to the generic message).
• The delete alerts in control-panel.js and bookmarks.js use it.

Testing

• 3 new backend tests: unlink PermissionError → 403 naming the file (and confirming the failed delete leaves file + index row intact), TrashPermissionError → 403 with the Settings suggestion, generic trash OSError → 500 carrying the OS reason.
• 2 new Jest tests for errorDetail (prefers detail; falls back for missing/non-string detail and non-HTTP errors).
• Full suites green (27 backend in test_index.py, 424 frontend); ruff / eslint / prettier clean.
• Also exercised against a genuinely read-only directory (chmod 555): both the unlink and trash paths produce the messages above, and manually verified in the running app.

Follow-up

Once this and #351 are both merged, the batch delete_images endpoint's per-item errors list (currently raw exception strings) should reuse _remove_image_file() for the same actionable wording.

🤖 Generated with Claude Code