Scheduling Phase B: job routing (service areas, load/proximity assignment, booking rules)

[important-new]

Phase A of the scheduling program (My Schedule, blocks, holidays, slot engine) shipped in #252 / #255. Phase B — routing — is not yet started.

Scope

• Service areas: per-inspector zip/region eligibility.
• Routing strategies beyond first-available: least_loaded and closest. Today pickInspector in server/lib/booking/booking.service.ts sorts eligible users by (name, id) and returns the first.
• Booking rules: minimum lead time + same-day cutoff time on tenant_configs.

Deliverables: service-area schema + API + settings UI; routing-strategy selection; booking-rules engine.

[important-new]

Shipped in #299.

All three deliverables landed: inspector_service_areas schema + API + settings UI; routing-strategy selection (first_available / least_loaded / closest); and the booking-rules engine (minimum lead time + same-day cutoff on tenant_configs).

Two things worth knowing beyond the scope as written:

pickInspector now returns a decision — { requested, applied, reason, candidateCount } — rather than a user id, and every substitution is logged and written to audit_logs. That exists because each strategy has a degenerate case that would otherwise be silent: least_loaded ties at zero when no work is dated, and closest has nothing to sort by when the property was never geocoded. Both now name a reason (no_dated_work, property_ungeocoded, no_anchored_candidate) instead of quietly behaving like first_available.

closest also needed anchors that did not exist: company coordinates geocoded from the address already on file, per-inspector service origins, and address capture on the public booking form — which turned out to be wiring rather than construction, since the geocode endpoint already returned zip and placeId and nothing called it.