docs: fill migration-workflow gaps found in final review

CLAUDE.md:
- Add the one-time `prisma migrate resolve --applied 0_init` baseline
  step that must run before the first `migrate deploy` against any
  environment (o2switch production included) whose conversion_jobs
  table predates Prisma. Without it, migrate deploy tries to
  CREATE TABLE against a table that already exists and fails, leaving
  migration history stuck.
- Document the actual, tested result of `prisma migrate dev` against
  the local dev DB: it fails with P3014 because convert_user lacks
  CREATE DATABASE/DROP DATABASE privileges needed for the shadow
  database. Document the verified fallback (`migrate diff
  --from-migrations ... --to-schema-datamodel ...` + manual migration
  folder + `migrate resolve --applied`) as the supported way to create
  new migrations here.

README.md:
- Local development step 2 referenced the deleted db/schema.sql;
  replaced with the real `prisma migrate deploy` invocation, which
  creates conversion_jobs fresh on an empty local database. Reordered
  so `npm install` runs first, since the migrate command needs
  node_modules/@prisma/client.
- Deployment on o2switch: added the same one-time baseline step
  (clearly marked, not to be repeated) before the first migrate
  deploy on that server, and added `prisma migrate deploy` to the
  "every subsequent deployment" checklist, after npm install and
  before restarting the app.

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

CLAUDE.md

@@ -61,9 +61,27 @@ Fall back to Grep/Glob/Read **only** when the graph doesn't cover what you need.
 
 - `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`:
+- **`prisma migrate dev` does NOT work against the local dev DB** — verified by actually running it (`DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate dev --name test_shadow_db_probe`). It needs to create/drop a temporary shadow database to detect schema drift, and the local `convert_user` does not have `CREATE DATABASE`/`DROP DATABASE` privileges, so it fails immediately with:
+  ```
+  Error: P3014
+  Prisma Migrate could not create the shadow database. Please make sure the database user has permission to create databases.
+  Original error: Error code: P1010
+  User was denied access on the database `prisma_migrate_shadow_db_...`
+  ```
+  No migration folder is created when it fails this way (it errors before writing anything), so nothing needs cleaning up afterward. Do not use `migrate dev` in this project until `convert_user`'s privileges change.
+- To create a new migration locally after editing `prisma/schema.prisma`, use the shadow-database-free fallback instead (the same pattern Task 3 used for the `0_init` baseline):
   ```
   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>
+    DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate diff \
+    --from-migrations prisma/migrations --to-schema-datamodel prisma/schema.prisma --script > migration.sql
+  ```
+  Review `migration.sql`, then manually create the next `prisma/migrations/<timestamp>_<description>/migration.sql` folder with that content, and mark it applied without executing it (since you'll apply it for real via `migrate deploy` or by hand):
+  ```
+  DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate resolve --applied <timestamp>_<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.
+- **ONE-TIME step, required before the very first `migrate deploy` against any environment whose `conversion_jobs` table predates Prisma** (this includes o2switch production, which still has the table created by hand from the now-deleted `db/schema.sql`, but no `_prisma_migrations` tracking table): do **not** run `migrate deploy` first. Instead, baseline that environment exactly like Task 3 did locally:
+  ```
+  DATABASE_URL=$(node scripts/printDatabaseUrl.js) npx prisma migrate resolve --applied 0_init
+  ```
+  This tells Prisma that `0_init` is already applied (the table already exists) without trying to `CREATE TABLE` it again. Run this once, ever, per environment — after that, `migrate deploy` is the correct command for all subsequent deployments to that environment. Running `migrate deploy` first (without this baseline step) against such an environment will fail with a MySQL "table already exists" error and leave Prisma's migration history in a failed state requiring manual recovery.