Baseline Prisma Migrate against the existing conversion_jobs table

Marks 0_init as applied via prisma migrate resolve so Prisma's
migration history is in sync with the pre-existing conversion_jobs
table, without running any SQL against the table itself.

CLAUDE.md

@@ -56,3 +56,14 @@ Fall back to Grep/Glob/Read **only** when the graph doesn't cover what you need.
   ```
 - A local MariaDB is expected to already be running on `127.0.0.1:3306` with the `file_converter` DB and `convert_user` credentials seeded.
 - Known pre-existing failures unrelated to any fix: `test/cleanup.test.js` ("deletes an expired pending job...") and `test/jobs/jobRepository.test.js` ("finds expired jobs and allows deleting them") — both fail on `main` independent of other changes (looks like a clock/timezone mismatch around `expiresAt` comparisons, not yet root-caused). Don't assume a change caused these; verify against `main` first if they show up again.
+
+## Database schema & migrations
+
+- `prisma/schema.prisma` is the source of truth for the `conversion_jobs` schema; `prisma/migrations/` is its version history. `db/schema.sql` no longer exists.
+- Prisma CLI commands (`prisma migrate dev`, `prisma migrate deploy`, `prisma generate`) need `DATABASE_URL` in their own process environment, separate from the app. Compute it from the same `DB_HOST`/`DB_USER`/`DB_PASSWORD`/`DB_NAME` values used for local tests, via `node scripts/printDatabaseUrl.js` — never write `DATABASE_URL` into `.env` or `.env.local`.
+- To create a new migration locally after editing `prisma/schema.prisma`:
+  ```
+  DB_HOST=127.0.0.1 DB_USER=convert_user DB_PASSWORD=change_me DB_NAME=file_converter STORAGE_DIR=./storage \
+    DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate dev --name <description>
+  ```
+- To apply pending migrations in production: with the real `DB_*` values loaded from `.env`, run `DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate deploy` before starting the app.