fix(batch): roll seal repair back to 16 workers
Problem
#24729 raised prod seal-repair workers 16 -> 48. The first 48-worker pass (Job 29898605, 2026-11-05 22:05-22:31Z, image 6db2d43d) made throughput worse: all sampled row lines were budget_exhausted (the 270 s per-row cap). Per-row time went from ~150 s to >270 s, so ~0 rows sealed vs ~134 in the prior 16-worker pass. Pod resources were fine (CPU 1.8 of 4, memory 3.7 of 8 GiB, no throttling), so a shared per-row I/O path saturates at 48 concurrent rows. This meets the prod-safety rollback condition from #24729's review.
Fix
Prod recordSealRepair.workers back to 16 (values only). The code and chart cap stays at 64, so a later, measured step can use it once the per-row I/O bottleneck is profiled.
Failure-Class: none
(Rollback of a capacity step, not a defect class.)
Tests
test_record_seal_cluster_repair_deploy.py (prod renders 16): 10 passed.
Risk / rollback
Restores the pre-#24729 prod setting. An already-running Job keeps 48 until it ends (<=1500 s).
Evidence: omi-workspace data/run-2026-11-05-omi-pipeline/sealroll-24729-watch.txt.
š¤ Generated with Claude Code