feat: directions_tool route selection elicitation

[mattpodwysocki]

Summary

• Rebuilds the "let the user pick a route" idea from Add two-stage elicitations for DirectionsTool #99 (Stage 2 only — Stage 1 routing-preference elicitation is out of scope for this PR) against the current self-fetch/elicitation architecture, following the same pattern search_and_geocode_tool uses for disambiguation.
• When the Directions API returns 2+ route alternatives, directions_tool calls server.elicitInput(...) presenting each option's duration, distance, primary roads, traffic, and incident count, and returns only the selected route.
• Directions routes have no stable ID across separate API calls (unlike search's mapbox_id), so the selection is threaded through the self-fetch ref as a positional selectedRouteIndex, with a graceful fallback to routes[0] if it's out of range on re-fetch.
• Clients without elicitation support, users who decline, or elicitation errors all fall back to returning every route alternative — unchanged from current behavior.
• Corrects docs/elicitations.md, which (since Add geocoding disambiguation with elicitations #98) described a two-stage directions_tool flow and automatic client-capability detection that were never actually implemented.

Test plan

• npx tsc --noEmit -p tsconfig.src.json — clean
• npx eslint — 0 errors (pre-existing unrelated warnings only)
• New unit tests in DirectionsTool.test.ts covering: elicitation triggers at 2+ routes, doesn't trigger at 1, filters to selected route + threads selectedRouteIndex, falls back on decline/error/unsupported/no-server
• New unit tests in mapAppHtml.script.test.ts covering the client-side self-fetch: draws the route at selectedRouteIndex, falls back to first route when out of range, never fetches when the index isn't a valid non-negative integer
• Full suite passes (73/73 in the touched files)

🤖 Generated with Claude Code