Routes API + Address Validation (2026-08-05)

Session 71, entirely-api dfa749e.

What changed

Routes API enabled on GCP project unlikely-ops (Directions API’s v2 successor — legacy Directions had ZERO callers in the codebase; the key sat unused in config since it was added).
routing_service (services/routing_service.py): computeRoutes v2 wrapper. Traffic-aware DRIVE mode, field-masked to duration/distanceMeters/legs (Routes API bills by field mask). Uses GOOGLE_DIRECTIONS_API_KEY, falls back to GOOGLE_MAPS_API_KEY.
GET /ops/drive-time (verify_api_key): origin, destination, optional pipe-separated waypoints. Built for schedule planning (home → stop 1 → stop 2 drive times).
intake_enrichment_service: new Step 0 calls Address Validation API (already enabled, previously unused). Standardized USPS address feeds geocoding ONLY when addressComplete && !hasUnconfirmedComponents; verdict + USPS county + DPV exposed as enrichment.address_validation. Best-effort — any failure falls back to raw address, pipeline unchanged.

Intake review queue (IntakeRequests.tsx): “Check address” badge on the card when USPS couldn’t fully confirm (incomplete/unconfirmed); enrichment panel shows “USPS verified — {county}” when clean, or the unconfirmed/ missing components + closest USPS match when flagged. Collaborative wording per standing UI-language rule. Pre-2026-08-05 intakes lack the key and render unchanged.

The “100% error rate” on Directions/Geocoding in the console (2026-08-04) was the session-70 billing lapse; the failed requests were session-70’s own diagnostic calls. Nothing in production was broken by it except geocoding during the lapse window.
Verified live: computeRoutes Elkridge→Manassas 67.3 mi / 1h29m traffic-aware; validateAddress standardizes “9500 center street manassas va” → PREMISE/complete/DPV=Y, USPS county MANASSAS CITY; full enrich_intake in-container → City of Manassas jurisdiction + Valerio certifier.
Routes API pricing: Essentials tier free at current volume (<1K/mo).