wip: ops admin panel + migration sync + crud/rbac phase-5 snapshot

Working-tree checkpoint of in-progress work carried across prior
sessions on the feat/crud-rbac branch, committed so it lands on the
remote alongside the CI changes.

- Operaciones admin panel: apps/api/src/ops (ingest upload, backup /
  restore / re-import jobs) wired into app.module + RBAC abilities, and
  the apps/web/src/app/operaciones page. docker-compose gets INGEST_DIR
  / BACKUP_DIR volumes; .gitignore excludes migration/ingest + backups.
- migration/sync.py plus transform_*.py / run_all / config / dbenv /
  blob_extract adjustments for the additive sync path.
- crud/rbac phase-5 web bits: AppShell, api/labels/types libs, globals.
- schema.prisma + PLAN/RESUME doc updates.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

RESUME.md

@@ -162,6 +162,17 @@ the reconciliation pass (done, then corrected) are all closed. See §3 and §8.
 5. **`TRASPASOS PAYPAL` is a clearing account, not a customer** — carries -7.03M MXN over
    309 movements and therefore tops the adeudo worklist. Deliberately not special-cased in
    code; needs a business decision on how to model it.
+6. **DB Operations — Phase B (additive sync) — IMPLEMENTED, verification pending.** Phase A provides
+   the admin-only `/operaciones` page + `ops` API module (ability `db:manage`, ADMIN), ingest
+   folder, backup, restore, and destructive re-import. Phase B now enables `SYNC`: `OpsService`
+   creates a safety backup and runs `run_all.py --sync`; transforms upsert legacy-owned rows by
+   provenance keys while preserving existing PKs and rows whose `legacyId IS NULL` (manual).
+   Prisma now enforces provenance uniqueness for properties, policies, transactions, vehicles,
+   and bank transactions. Sync intentionally skips prune/blob steps so manual customers and
+   document pointers are not removed. Python compilation plus API/web production builds pass;
+   still required before production use: push updated Prisma schema and run an end-to-end sync
+   against a disposable/dev DB proving stable PKs, manual-row preservation, changed-row updates,
+   and legacy-delete handling.
 
 ## 7. Environment notes (current macOS machine)
 
@@ -374,11 +385,14 @@ for what's actually next.
 
 ---
 
-⏭ **NEXT — where to pick up:**
-
-- **Plan step 8–9: VPS + sync worker.** Blocked on VPS provisioning (§6.1) — the only real
-  external dependency left. Pure ops: provider, size, Tailscale, MySQL replica.
-- **Plan step 10: reports / email campaigns / admin.**
+- **Sync implementation — DONE, validation pending.** `run_all.py --sync` performs the
+  non-destructive legacy upsert path for customers, properties, policies, transactions, and
+  bank rows. It preserves manual rows and stable legacy-owned primary keys; the admin SYNC job
+  automatically creates a pre-sync backup. Next validation: apply schema changes, then exercise
+  sync against a disposable DB with added, changed, removed, and manually-created rows.
+- **Plan step 9: portal sync worker** remains separate and blocked on VPS provisioning. This
+  Phase B feature synchronizes Access source files into the internal platform; it does not yet
+  poll `utility_dbo` inbox tables or replicate portal-facing data to a VPS.
 - **Small / open:** (a) `TRASPASOS PAYPAL` clearing account still tops the adeudo worklist
   (§6.4d) — a business modelling call, not code. (b) Credential rotation on the old repo's
   exposed MySQL password. (c) The `/estado-cuenta` browser visual pass — `/banco` was verified