Backfill bleed_diff_mm by arithmetic recompute, not by re-extraction

[WilfordGrimley]

From PR #645's ruling, and it is a WRITE needing owner authorisation.

ImageEvidence.bleed_diff_mm is NULL on 215,921 of 220,579 rows (97.9%), and 213,131 of those NULLs sit on rows whose bleed_class is a confident bleed — so the abstain path demonstrably did not apply. The field and the line writing it were added without bumping geometry_bleed's extractor version, so every historical row read as current and was skipped.

PR #645 makes it reachable — a run-scoped bulk pass now re-extracts every card, so no version bump is needed for reachability. But that costs ~220,000 image fetches.

The cheap close: compute_bleed_diff_mm reads only card_image.size, and ImageEvidence.width / height are already stored and 0% NULL. So a no-fetch arithmetic recompute from stored columns is arithmetically identical to re-extraction.

What would close this

A backfill command doing the recompute from stored width/height, gated behind --write per this repo's convention, with a dry-run reporting the row count it would fill. Then one authorised run.

Note the version-bump question is separate and still live: a bump remains the right tool for the --only-never-extracted path that #645 preserves, where the stale-v1 trap still applies. It is not needed to close this field.

Related: #636, #637 (the field-level census), #645 (run-scoped resume), #590 (the extractor-manifest tether that would have caught the missing bump).

[WilfordGrimley]

Owner ruling, 2026-07-30: no separate backfill. bleed_diff_mm is built into the monolith.

"bleed_diff_mm needs to be built into the monolith, no need for backfill if that's done."

So this is not a one-off recompute command awaiting authorisation — it is a requirement on the monolith's Stage C. PR #645 already run-scopes the Stage C resume filter, so a monolith pass re-extracts every card and the field fills as ordinary output.

What still needs deciding inside that work: whether Stage C recomputes bleed_diff_mm from the fetched image (free, it is already decoding it) or from the stored width/height (also free, and identical arithmetic). Either fills the column during a normal pass. The ~220k-extra-fetches objection that motivated a separate backfill disappears entirely once the monolith is fetching those images anyway.

Re-scoping this issue accordingly: it is a line item on the monolith wiring, not standalone work. Nothing here needs a poll.

Related: #618 (monolith wiring), #645 (run-scoped Stage C resume), #636 (the missing version bump that made it unreachable).