Approval readiness must include the server's non-photo prerequisites

An approval UI can offer an action that the server correctly rejects when its fallback readiness check considers uploaded evidence but omits another prerequisite such as browser GPS. Use one authoritative readiness evaluator across every list/detail projection and the mutation boundary, and show a structured rejection reason beside the action. Logging an error and clearing a spinner leaves users unable to distinguish a rejected command from a hung request. This applies to multi-participant workflows too: one participant's completion must not imply group readiness. Keep administrative delivery overrides distinct from verification overrides.

Evidence/example — 2026-09-15: Read-only source inspection of Shield revision 175f0bde25789f1e556803915e0c0163bd0235ff found that types/loads.ts:isLoadReadyForReview checks contact/photo readiness, while lib/required-review-readiness.ts additionally requires browser GPS or an explicit exception for every driver. The load-details modal uses the former when the authoritative field is absent, and loads-table/index.ts only logs review failures. Source: https://github.com/e3-solutions/theft/blob/175f0bde25789f1e556803915e0c0163bd0235ff/web/src/lib/required-review-readiness.ts . This establishes a possible source-level mismatch, not its prevalence across all UI paths. Customer records, screenshots and logs are intentionally excluded.