booklore: enable the BookDrop watched-import folder (2.3.1-2)

[arquiguru]

What this fixes

BookLore's own App Store description highlights BookDrop as a headline feature:

Adding new titles is effortless thanks to the BookDrop feature. Instead of manually managing file names and directories, users can simply place a book into a designated space, and BookLore automatically processes it, retrieves the correct metadata, and adds it to the collection.

But the package never wired it up. BookLore watches a fixed container path /bookdrop (it is not configurable via env), and the compose file only mounts /app/data and /books. So on Umbrel the advertised drop folder maps to an ephemeral in-image directory the user can't reach, and BookDrop silently does nothing. Files placed anywhere the user can reach are never seen.

This is a package defect: the store listing promises a feature the package can't deliver.

User story

A user reads the description, expects a drop folder, and finds none. There is no supported way to use BookDrop on Umbrel without hand-editing the compose file after every app update.

The change

Following this repo's umbrel-update-app / umbrel-package-app skill guidance for adding a shared-Downloads bind mount:

1. docker-compose.yml — mount a BookDrop subfolder of Umbrel's shared Downloads storage at the fixed /bookdrop path:

   - ${UMBREL_ROOT}/data/storage/downloads/BookDrop:/bookdrop

   Uses the compatibility data/storage/downloads path that current umbrelOS rewrites to home/Downloads at patch time, per the skill's storage guidance. This surfaces the folder in the Files app and on the network share, so users can drag books straight in.

2. umbrel-app.yml — declare permissions: [STORAGE_DOWNLOADS] (same as transmission, navidrome, audiobookshelf, metube, which also mount Downloads or a subdir), and add user-facing releaseNotes explaining the new folder and that BookLore moves each file out of the folder into the library after a successful import (the folder emptying itself is expected, not data loss).

3. hooks/pre-start — idempotent migration modeled on navidrome/hooks/pre-start: create the host-side BookDrop folder and chown it to the container's uid/gid (1000:1000) before containers start, so both fresh installs and updates of existing installs get a writable folder. It resolves both path generations (home/Downloads/BookDrop on current umbrelOS, data/storage/downloads/BookDrop on older), since the hook itself is not rewritten by umbreld.

No change to the BookLore application image; this is packaging-only. Version bumped 2.3.1-1 → 2.3.1-2 so existing installs are offered the update.

Testing

Tested on UmbrelOS (Debian 13, kernel 6.12, x86_64) against a live BookLore install carrying real user data.

• Update path, not just fresh install. Ran the pre-start hook logic against an existing install and recreated the web container with the new mount.
• Mount: docker inspect confirms .../home/Downloads/BookDrop -> /bookdrop (umbreld rewrote the packaged data/storage/downloads/BookDrop path to home/Downloads/BookDrop, exactly as the skill documents). App stays on umbrel_main_network; web UI returns HTTP 302 (login redirect = healthy).
• Hook: created home/Downloads/BookDrop owned 1000:1000, idempotent on re-run.
• Detection end-to-end: dropped a test EPUB into the folder with uid-1000 ownership (as the network share writes it). BookLore's watcher detected it within seconds → a PENDING_REVIEW row appeared in the bookdrop_file table, i.e. it showed up on the app's Bookdrop review page.
• Full import cycle, end-to-end as a real user: dropped an EPUB into Downloads/BookDrop from macOS Finder via the Umbrel network share → BookLore's watcher detected it in ~2 seconds and extracted cover art → clicked Import on the Bookdrop review page → file moved into the library (/books/<Author>/<Title>/…), record finalized (Success: 1, Failed: 0), and the source file was deleted from the drop folder (self-emptying confirmed).
• Data safety: library book count unchanged (34 before and after); bookdrop_file table reconciled cleanly after the test file was removed; existing /app/data, /books, and /var/lib/mysql mounts untouched.

Notes

• npm run lint:apps -- booklore --check-images: 0 errors, 1 pre-existing warning — the mariadb:12.0.2 tag digest has moved upstream since it was last pinned. That is unrelated to this PR, so the existing digest is left as-is per the linter's own guidance.
• Prior BookLore package work: booklore: whitelist OPDS + KOReader sync paths in app_proxy #5832 (app_proxy OPDS/KOReader whitelist).

Architecture tested: linux/amd64. No breaking changes; no migration action required from users.