Node 20 → 24, and say what is wrong when the data directory is not writable

Node 20 left maintenance in April 2026, so a production instance was
running an interpreter that no longer gets security fixes.

The upgrade needed better-sqlite3 as well. On Node 24 the version we
pinned (^11) aborts inside the native addon —

  node[1]: void node::RemoveEnvironmentCleanupHook(...) at hooks.cc:142
  Assertion failed: (env) != nullptr

— so bumping only the base image would have shipped a server that dies on
shutdown. Raised to ^12, which handles Node 24; verified against a copy of
a real database that existing encrypted notes and version history still
decrypt, and that SIGTERM now closes cleanly.

Separately: a bind-mounted data directory the container cannot write to
surfaced as "SqliteError: unable to open database file" out of
better-sqlite3, which points at the database when the problem is on the
host. Startup now checks both directories and says which uid it runs as,
who owns the directory, and what to run to fix it.

Frontend build now copies the lockfile and uses npm ci, so the image is
built from the dependency versions that were tested.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

frontend/dockerfile

@@ -1,7 +1,9 @@
-FROM node:20-alpine AS build
+FROM node:24-alpine AS build
 WORKDIR /app
-COPY package.json ./
-RUN npm install
+# The lockfile comes along so the image is built from the same dependency
+# versions that were tested, rather than whatever resolves on build day.
+COPY package.json package-lock.json ./
+RUN npm ci
 COPY . .
 RUN npm run build