docs: card-location Step 1 gate result — NOT MET, no replacement shipped

[WilfordGrimley]

Description

Attempted the fix docs/reports/2026-08-06-crop-geometry-audit.md (issue #735) called for:
locate each card's own rectangle inside its (possibly canvas-padded) image using the rules-text-
box's bottom edge as an internal landmark, then rebuild classify_bleed_edge/compute_bleed_diff_mm
and classify_border_color/frame-continuity on top of that located rectangle instead of the
image's own fixed fractions.

Step 1 (locate the card) did not clear its own gate, so steps 2 and 3 were not attempted.
Measured against pixel-level ground truth on the 4 cards the prior audit named as confirmed
misclassifications (30255/84481/95604/182512): 0/4 got a correct rectangle (3 abstained, 1 wrong by
more than an order of magnitude). 39.3% confident rate over a 28-image stratified sample overall.
Root cause: the method's single global "text-box-bottom-as-fraction-of-card-height" constant (f)
and its symmetric-padding assumption both measured false across this catalogue's actual template
diversity — see the report for the pixel-level evidence.

No code changes ship in this PR. classify_bleed_edge, compute_bleed_diff_mm,
classify_border_color, local_art_edge.classify_art_edge_continuity, every *_CROP_BOX/
_BORDER_SAMPLE_BANDS constant, image_evidence.py's extractor wiring, and golden_set.py's
pinned values are byte-identical to master. No migration. No version bump. This PR's only content
is the gate-result report and two concrete, unattempted follow-up directions for whoever picks this
back up.

Full report: docs/reports/2026-08-06-card-location-landmark-gate.md

Checklist

• I have installed pre-commit and installed the hooks with pre-commit install before creating any commits.
• I have updated any related tests for code I modified or added new tests where appropriate. — N/A, no code changed (see report's Gate verdict).
• I have manually tested my changes as follows:
  • Fetched 28 real catalogue images (24 stratified by bleed_class/source/layout, 4 named by the
    prior audit as confirmed misclassifications) via the public CDN Worker route, paced under
    GOOGLE_IMAGE's rate ceiling.
  • Derived f≈0.90 by direct visual inspection (fine gridline overlays, viewed with the read
    tool) of 6 independent card renders, cross-checked against local_ocr.DEFAULT_CROP_BOX's own
    pre-existing empirically-tuned constant.
  • Built a standalone prototype detector implementing the brief's own formula and ran it against
    all 28 images: 11/28 confident, 17/28 abstained.
  • Pixel-verified (direct RGB sampling along image centre rows/columns, not eyeballing) the
    detector's answer against ground truth on 2 of the 11 confident cases, including 1 of the 4
    audit-flagged cards — found the flagged case wrong by >10x, the general-sample case
    directionally right but not to a trustworthy precision.
  • Checked host load (uptime) and sfc-* unit activity before and during fetching; load stayed
    3.0–4.8 throughout, 0 sfc-* units active.
• I have updated any relevant documentation or created new documentation where appropriate. —
  new dated report (docs/reports/2026-08-06-card-location-landmark-gate.md) + its
  docs/reports/README.md index entry. docs/identification-pipeline.md/
  docs/pipeline-fidelity-gate.md are unchanged since no detector's behaviour changed.

Task-end checks

• Backend tests: not run — no Python/test files changed in this PR (docs-only).
• docs_lint.py / constant-rename-equivalence: N/A — no constants renamed, moved, or added.
• New ImageEvidence fields / migration: none.
• Extractor version bumps: none — see report's "What changed in code" for why bumping either
  GEOMETRY_BLEED_EXTRACTOR_VERSION or LAYOUT_CLASS_EXTRACTOR_VERSION here would be dishonest
  (no computation changed).
• Wiki: no user- or admin-visible behaviour changed; nothing to update.
• Extractable-primitives ledger: no extraction/refactor in this PR; nothing to add or remove.