PR #40 merged: fix(deploy): stop the database volume shadowing migrations

What

Prod never ran a migration shipped after 2026-06-30, because the compose mounted the SQLite volume at /app/database — shadowing the image's database/migrations/ directory. Boot-time migrate saw only the stale volume copy of the migrations dir, reported "Nothing to migrate", and the entrypoint's || true swallowed every trace. First casualty: inference_jobs.progress (#39) — new code live, column missing, pack jobs dead on arrival with no such column: progress.

Changes

• compose: same named database volume (data carries over — it's re-mounted, not recreated), mount moved to /data/db, and DB_DATABASE=/data/db/database.sqlite set in the app env. The image's database/migrations/ is now visible to artisan migrate.
• Dockerfile: pre-creates /data/db with the same ownership as the other runtime dirs.
• entrypoint: migrate failures still don't crash-loop the container (transient SQLite locks shouldn't take the app down), but they now shout !!! MIGRATE FAILED to stderr instead of vanishing.

Deploy notes

• The existing DB file sits at the volume root, so after the remount it's at /data/db/database.sqlite — no data copy needed. (The volume also contains a stale frozen copy of migrations//factories//seeders/ from its first-ever mount; harmless clutter, can be cleaned any time.)
• Prod's progress column + its migrations row were already reconciled manually tonight, so first boot after this should log "Nothing to migrate" — from the real directory this time.
• Verify the deploy actually goes out (the webhook build died on resource exhaustion earlier tonight and needed an API retry).

🤖 Generated with Claude Code