fix(migration): make 0045 DDL-only; backfill image_prediction via batched task (#768)

The inline INSERT…SELECT backfill in migration 0045 wrapped the table
creation and a ~100 GB pass over image_record.tagger_predictions in one
transaction: nothing committed until the end, it was unmonitorable, and an
earlier MATERIALIZED-CTE form spilled the full 100 GB to temp on NFS. A
deploy got stuck on it for ~2h with image_prediction never appearing.

Split the concerns:
- 0045 now creates ONLY the table + indexes (instant DDL → web boots).
- New backend.app.tasks.admin.backfill_image_predictions_task copies the
  >= store-floor predictions from the JSON into image_prediction, batched by
  id window and committed per chunk: live progress, resumable (re-enqueues
  from the last committed id), idempotent (ON CONFLICT DO NOTHING). json_each
  stays in the DB executor streaming each window — no Python-side 100 GB load,
  no materialization.
- POST /api/admin/maintenance/backfill-predictions + a Maintenance-tab card
  to trigger the one-time run after upgrading.

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

alembic/versions/0045_image_prediction_table.py

@@ -1,13 +1,22 @@
-"""image_prediction table + backfill from image_record.tagger_predictions
+"""image_prediction table (DDL only — backfill runs as a background task)
 
 Normalizes the per-image tagger predictions out of the JSON blob into a
-queryable table (#768). Backfills from the existing JSON in one set-based
-INSERT…SELECT over json_each — fast because the #764 prune already shrank
-each row to its >=0.70 entries. The old image_record.tagger_predictions
-column is left in place here (vestigial) and dropped in a follow-up once the
-code cutover is verified — dropping it needs an ACCESS EXCLUSIVE lock on the
-hot image_record table (the 0044 lock class), so it's deferred to a
-quiesced-worker window.
+queryable table (#768). This migration creates ONLY the table + indexes — it
+is pure DDL and commits instantly, so web boots immediately.
+
+The data backfill from the existing image_record.tagger_predictions JSON is
+deliberately NOT done here. Doing it inline made the whole migration one
+transaction over the ~100 GB TOAST: nothing committed until the very end, it
+was invisible/unmonitorable mid-run, and an early MATERIALIZED-CTE form spilled
+the full 100 GB to temp. Instead the backfill is the
+backend.app.tasks.admin.backfill_image_predictions_task — batched by id window,
+committed per chunk (visible progress + resumable), idempotent
+(ON CONFLICT DO NOTHING). Trigger it from Settings → Maintenance once web is up.
+
+The old image_record.tagger_predictions column is left in place (vestigial) and
+dropped in a follow-up once the backfill + code cutover are verified — dropping
+it needs an ACCESS EXCLUSIVE lock on the hot image_record table (the 0044 lock
+class), so it's deferred to a quiesced-worker window.
 
 Revision ID: 0045
 Revises: 0044
@@ -48,40 +57,10 @@ def upgrade() -> None:
         "ix_image_prediction_name_score", "image_prediction",
         ["raw_name", "score"],
     )
-    # Backfill from the JSON blob. json_each expands {name: {category,
-    # confidence}} into one row per prediction. category defaults to 'general'
-    # to mirror the suggestion read path; rows with no confidence are skipped.
-    # Filter to >= the store floor (ml_settings.tagger_store_floor, default
-    # 0.70) right here so this is self-sufficient — it does NOT depend on the
-    # #764 prune having run, and extracting only the >=floor tail keeps
-    # image_prediction small (~tens of rows/image) even from the full JSON.
-    # Guard json_each against non-object rows (some tagger_predictions are JSON
-    # scalars/null → "cannot deconstruct a scalar"). The inline CASE passes an
-    # empty object for those, so json_each yields nothing — a single STREAMING
-    # pass with NO materialization/temp spill (an earlier MATERIALIZED-CTE guard
-    # forced ~100 GB to temp on NFS and was pathologically slow).
-    op.execute(
-        """
-        INSERT INTO image_prediction (image_record_id, raw_name, category, score)
-        SELECT ir.id,
-               je.key,
-               COALESCE(je.value ->> 'category', 'general'),
-               (je.value ->> 'confidence')::double precision
-        FROM image_record ir,
-             json_each(
-                 CASE WHEN json_typeof(ir.tagger_predictions) = 'object'
-                      THEN ir.tagger_predictions
-                      ELSE '{}'::json END
-             ) je
-        WHERE je.value ->> 'confidence' IS NOT NULL
-          AND (je.value ->> 'confidence')::double precision
-              >= COALESCE(
-                  (SELECT tagger_store_floor FROM ml_settings WHERE id = 1),
-                  0.70
-              )
-        ON CONFLICT (image_record_id, raw_name) DO NOTHING
-        """
-    )
+    # No data backfill here — see the module docstring. The one-time copy from
+    # image_record.tagger_predictions runs as backfill_image_predictions_task
+    # (batched, resumable, idempotent), kept out of this transaction so web boots
+    # without waiting on a ~100 GB pass.
 
 
 def downgrade() -> None: