docs: prove the migration and seed against dev Postgres

Five migrations were pending, not one: this dev database had not been
migrated since the prosthesis overhaul landed on master. Used migrate deploy
rather than migrate dev so no drift prompt could offer a reset, and counted
the DELETE first — 0 rows matched against 2 total.

Seeded translations verified: 7 categories and 5 subcategories in fa, en and
nl, with crown resolving to روکش‌ها. Both login accounts survived.

Also records that .gitea/workflows run no test, lint or typecheck step at
all, which is why two spec-file type errors reached the branch unnoticed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/specs/voice-treatment-entry/progress.md

@@ -488,3 +488,45 @@ This is decision 39 behaving exactly as approved: teeth and prosthesis apply tog
 means a clinician who wants only the teeth from a prosthesis dictation, intending to pick
 materials by hand, has no way to get them. Not a spec violation — an unstated consequence.
 Deliberately not changed unilaterally.
+
+---
+
+## 2026-09-07 — Migration and seed proven against dev Postgres
+
+The last unverified gate. The inspector had run `prisma validate`, which only parses the schema;
+the build compiled solely because the generated client in `node_modules` already carried the new
+enum values.
+
+Found five migrations pending, not one — this dev database had not been migrated since the
+prosthesis overhaul landed on `master` on 1 September (`a3c14a1`, `72f885d`). Prisma applies in
+order, so proving one required applying all five.
+
+Used **`prisma migrate deploy`, not `migrate dev`**: `deploy` applies pending migrations and never
+offers to reset, so there is no path where a drift prompt drops dev data. §12 should say `deploy`
+for this reason.
+
+Counted the `DELETE` in `…_prosthesis_tree_multi_type` before applying rather than trusting its
+own "no-op for current data" comment: **0 rows matched**, against 2 rows total in
+`lab_case_tooth_prosthesis`. Both login accounts survived (`users` = 2).
+
+Verified after seeding:
+
+| Check | Result |
+|---|---|
+| `enum_range(CatalogEntityKind)` | now 5 values, including `PROSTHESIS_CATEGORY` and `PROSTHESIS_SUBCATEGORY` |
+| Seeded `PROSTHESIS_CATEGORY` rows | 7 per locale × fa/en/nl |
+| Seeded `PROSTHESIS_SUBCATEGORY` rows | 5 per locale × fa/en/nl |
+| `crown` in `fa` | `روکش‌ها` — the label that makes "روکش" resolvable to a category |
+| Code path | `prosthesis-catalog.service.ts:108,119` resolves both kinds via `CatalogLabelService` |
+
+**Repo-wide gap worth acting on separately:** `.gitea/workflows/*` run no test, lint or typecheck
+step — only build and deploy. Combined with `nest build` excluding `**/*spec.ts` and ts-jest
+running transpile-only under `isolatedModules`, nothing in this repo would ever catch a type error
+in a spec file. That is how two of them reached this branch unnoticed.
+
+## Remaining before this is shippable
+
+- The **manual pass in §12** — none of it has been run. Safari and iPad especially, since that is
+  the report that started the revision, and the stack / jaw / chip flows in `fa`.
+- The Ship phase cannot pass in this repo: no MR template exists, and opening a merge request is
+  gated regardless.