flight-cli: make the calendar GF+Matrix weave concurrent (work-6nrqf)

[ak2k]

Summary

Makes the one-way / single-airport calendar weave concurrent (work-6nrqf).

Previously the calendar ran the Google Flights date-grid (~1s, up to ~9s cold) and painted it, then ran the Matrix calendar (~45s) — sequential, so the GF time stacked on top of Matrix.

New _run_calendar_enriched dispatches both under one anyio.run, mirroring the search path's _run_enriched_path: start_soon the Matrix calendar, run the sync GF date-grid in a worker thread concurrently, paint the grid first while Matrix is in flight, then paint the authoritative Matrix calendar. Total wall ≈ max(GF, Matrix) ≈ Matrix alone.

Behavior

• Per-backend error isolation: a GF throttle (GfThrottledError) or failure still runs + paints Matrix; a Matrix error still shows the GF grid, and exits non-zero only when neither backend produced anything.
• --fast unchanged — GF date-grid only, no Matrix (the original block, preserved verbatim, just gated on fast).
• The concurrent path is gated by grid_can_serve, which guarantees a single-airport query, so the Matrix side is a single execute (no fan-out, no merge — the GF grid and Matrix calendar are separate paints).

Tests

3 new orchestration tests in test_calendar_split.py (happy path + GF-throttle isolation + Matrix-error isolation), fakes for both backends, no network.

• make check green (504 tests).
• Live-smoked: GF grid paints ~1s then Matrix; total ≈ Matrix alone; both error-isolation paths fired live (Matrix brownout + GF throttle); --fast verified unchanged.