Harden the API and the data layer after a security and performance audit

Security
- Every route now requires a login and refuses ids outside the caller's
  workspace with 404: plan, leave-wishes, day-overrides and vacation-days
  were fully anonymous; every other router trusted client-supplied
  workspace/child/parent ids. Scraper sessions are bound to their owner.
- Invitations can no longer be created for a foreign workspace, and a
  redeemer who is already a member (or a full workspace) is refused.
- Production refuses the default JWT secret; API docs are hidden in
  production; a failed migration aborts startup instead of serving.
- Login and register no longer reveal whether an email exists; inactive
  accounts are rejected; /auth/refresh is rate limited.
- The FK scraper writes debug artefacts only when explicitly enabled,
  logs no scraped values or page text, clears the BankID QR as soon as it
  is scanned and purges finished sessions after five minutes.
- Real FK page captures are removed from the tree (history rewrite
  follows); the parser tests use a synthetic fixture.

Performance and correctness
- Plan apply/sync run inside one locked transaction with batched writes
  instead of one commit per row, so a failure mid-batch leaves nothing
  half-applied and concurrent syncs no longer corrupt each other.
- SQLite runs in WAL mode with a busy timeout; 14 indexes cover the
  filters that were full scans; argon2 hashing runs off the event loop;
  responses are gzipped.
- Frontend: a 401 now refreshes the token once and retries, so sessions
  no longer die silently after 15 minutes; every data hook discards
  stale responses; logout clears state even when the server call fails.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CsXCCcDfmV4Sps4ZQSvNEY

backend/app/repositories/planned_leave_repository.py

@@ -43,3 +43,33 @@ class PlannedLeaveRepository(Repository[PlannedLeaveDay]):
         that DELETE runs, no `planned_leave_day` row still references this
         wish, so there is nothing left to orphan.
         """
+
+    @abstractmethod
+    async def create_many(self, items: list[PlannedLeaveDay]) -> None:
+        """Bulk-insert rows in one round trip (`executemany`). Empty list is a no-op.
+
+        See backend-perf audit H1: a per-row `create()` + `commit()` loop
+        measured 88.7ms/300 rows (default journal mode); this + one
+        surrounding `unit_of_work()` is the batched replacement used by
+        `PlanningService.apply_proposed_days` stage 4.
+        """
+
+    @abstractmethod
+    async def delete_many(self, ids: list[UUID]) -> int:
+        """Delete rows by id in one or more `executemany`/`IN (...)` round trips.
+
+        Idempotent: an id with no matching row is silently ignored rather than
+        raising `NotFoundError` (unlike `delete()`) — callers that already
+        know some keys may have vanished (e.g. a re-applied batch) should not
+        have to pre-filter. Returns the number of rows actually deleted.
+        """
+
+    @abstractmethod
+    async def update_metadata_many(self, pairs: list[tuple[UUID, UUID | None, bool]]) -> None:
+        """Bulk-update `(wish_id, is_pinned)` for existing rows via `executemany`.
+
+        Each pair is `(id, wish_id, is_pinned)`. Does not touch `day_type`/
+        `is_dubbeldag` — this is for the metadata-only path in
+        `apply_proposed_days` (a row whose type is unchanged but whose
+        `wish_id`/`is_pinned` differ from the incoming batch).
+        """