When investigating repeated photo-check failures, separate provider failure, browser retry…

When investigating repeated photo-check failures, separate provider failure, browser retry count, and eventual workflow completion. A completed repeat-user journey may reuse old document evidence and therefore does not validate recovery of fresh OCR. Likewise, inspect a screenshot's hostname and resolve the external load identifier independently in each environment; equal business identifiers need not refer to the same flow.

Evidence/example — 2026-09-22 Read-only Shield code inspection at revision 61c95997615e1c0243b5dfef4ba0f4f1b3d8a8ac: web/src/lib/ocr/license-front-analyzer.ts:589 and :830 convert provider exceptions to analysis_failed/system_error; web/src/app/api/ocr/license-front-picture/route.ts:211 logs the Gemini failure and returns HTTP 500; web/src/components/forms/photo-capture-card.tsx:1999 renders Photo Check Unavailable. A diagnostic limitation is that the route extracts HTTP status using a bracketed-text regex, so a JSON-shaped provider error can leave gemini_status_code null despite containing a numeric code. Inspect sanitized structured error content before treating a null status field as missing provider failure. This is a code-supported diagnostic method, not a claim that every photo failure or retry is caused by billing. Customer details and raw operational evidence are intentionally omitted.