fix(file-watcher): bound concurrent photo processing (#846)

* fix(file-watcher): bound concurrent photo processing

chokidar fires 'add' once per file — with no ignoreInitial option the
boot scan fires it for every existing file, and a bulk drop into the
watch folder fires it for every new one at once. Each handler runs DB
lookups plus (for new files) a full sharp pipeline; sharp.concurrency(2)
only caps libvips threads WITHIN one operation, not the number of
parallel pipelines, so unbounded handlers can OOM small hosts.

Gate both 'add' and 'unlink' through a shared p-limit
(FILE_WATCHER_CONCURRENCY, default 2, floor 1) — mass deletes otherwise
burst DB work and ZIP-cache invalidation the same way. p-limit is pinned
to ^3.1.0, the last CommonJS release.

Adapted from the filpgame fork (426ca491) — thanks @filpgame; extended
to cover 'unlink', documented in .env.example, plus a lock-in test for
the existing Sharp cache/concurrency caps this bound relies on.

* chore(compose): pass FILE_WATCHER_CONCURRENCY into the backend container (codex review of #846)

The backend service uses an explicit environment list (no env_file), so
the documented override never reached the container in the default
compose deployments. Added to both compose files + root .env.example.

backend/.env.example

@@ -106,6 +106,12 @@ ARCHIVE_PATH=/app/storage/events/archived
 # EVENTS_PATH=./storage/events
 # ARCHIVE_PATH=./storage/events/archived
 
+# File watcher (auto-import from the events/active folder, local storage only)
+# Max photos processed in parallel by the watcher. The boot scan and bulk
+# folder drops fire one handler per file — this bound keeps thumbnail
+# generation from exhausting memory on small hosts. Default: 2
+# FILE_WATCHER_CONCURRENCY=2
+
 # Analytics Backend Configuration (OPTIONAL)
 # Used for server-side tracking only
 # Primary configuration should be done through Admin UI > Settings > Analytics