Migrate before build, not just before start, to fix build-time SQLITE_BUSY

next build's page-data collection runs several parallel workers that each
import the db client at module-eval time. When data/db.sqlite doesn't
exist yet, every worker raced to create it from scratch — a race at the
file-creation level itself, before our code ever gets to run a
busy_timeout pragma, so pragma ordering alone (previous commit) wasn't
enough to fix it. Running db:migrate as its own isolated, single-process
build step first means the workers only ever see an already-existing,
already-stable file. The runtime volume-mounted DB is unaffected — it's
still migrated again (as a no-op once applied) by the existing CMD.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012o9j9RezxbZVKQMrB7oRLY

Dockerfile

@@ -12,6 +12,14 @@ COPY package.json package-lock.json ./
 RUN npm ci
 
 COPY . .
+# `next build`'s page-data collection spins up several parallel workers that
+# each import the db client at module-eval time. If data/db.sqlite doesn't
+# exist yet, every worker races to create it from scratch — that race is at
+# the file-creation level, before our code ever gets to run a busy_timeout
+# pragma, so it can throw SQLITE_BUSY (or worse) independent of pragma order.
+# Migrating first — as its own isolated, single-process step — means the
+# workers only ever see an already-existing, already-stable file.
+RUN mkdir -p data && npm run db:migrate
 RUN npm run build
 
 ENV NODE_ENV=production