fix(dispatch): presence is three-state — absent status key is unknown, not off-duty

The previous commit treated a missing miler_status:<id> key as "not available".
In production only 2 of 34 milers have that key at all, so the agent would have
reported "no available rider" for nearly every failure — a confident wrong
answer in the opposite direction from the bug it fixed.

- _miler_presence returns available / unavailable / unknown. No key, an
  unparseable value, or an unrecognised status reads as unknown.
- _find_zone prefers a confirmed-available miler, otherwise reports the nearest
  unknown-presence one (it may well be assignable), and returns None only when
  every nearby candidate is confirmed off duty.
- Facts carry nearest_miler_within_km + nearest_miler_presence; the prompt
  states plainly that unknown presence is not evidence of a coverage gap and
  should lean to monitor/escalate rather than ops_alert.
- New eval case for riders-nearby-but-no-presence-data; tests for all three
  presence states.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012AJLYcbTHCe45fyFnMfEin

core/llm.py

@@ -181,13 +181,20 @@ fallback failed, so no rider was assigned. Decide how to react. Choose exactly o
 - "ops_alert": a genuine coverage gap in this zone (repeated failures, no nearby riders). Alert operations to onboard or redirect riders here.
 - "escalate": ambiguous or contradictory — e.g. riders ARE nearby yet assignment keeps failing, which suggests a systemic issue rather than a coverage gap. A human dispatcher should look.
 
-Weigh how many times assignment has failed in this zone today, how far the nearest *available* rider is,
-the time of day, and whether coordinates were even available. "nearest_available_miler_within_km" counts
-only riders whose live status is Available; "milers_in_geo_index_within_30km" is the raw count of riders
-ever seen nearby (it includes off-duty and stale entries), so a large index count with no available rider
-means riders exist here but nobody is on duty — a staffing gap, not a systemic fault. A single failure with
-an available rider nearby is usually transient; repeated failures with no available rider is a coverage
-gap; repeated failures *despite* available riders nearby is not a coverage gap and warrants a human.
+Weigh how many times assignment has failed in this zone today, how far the nearest rider is and whether
+that rider is actually on duty, the time of day, and whether coordinates were even available.
+
+Read the rider facts carefully:
+- "nearest_miler_within_km": distance to the nearest rider in the location index.
+- "nearest_miler_presence": "available" = the backend confirms that rider is on duty;
+  "unavailable" = confirmed off duty / on break; "unknown" = there is NO presence data for nearby
+  riders. Unknown is not evidence of a coverage gap — do not treat it as "nobody is working".
+- "milers_in_geo_index_within_30km": raw count of riders ever seen nearby, including stale entries.
+
+A single failure with a rider nearby is usually transient. Repeated failures with no rider at all within
+30 km is a genuine coverage gap. Repeated failures *despite* a confirmed-available rider nearby is not a
+coverage gap but a systemic issue — escalate to a human. When presence is unknown, lean toward monitoring
+or escalating for a human to check rather than declaring a coverage gap.
 Report an honest confidence in [0, 1]."""
 
 _ASSIGNMENT_SCHEMA = {