feat(okw): typed coordinate accessor + structured lat/lon in API

[touchthesun]

What

Groundwork for the dashboard geographic map (review note #1): give OKW facilities a single, tested way to surface their location as numeric lat/lon, so the web map can plot them without re-parsing strings.

Turns out the OKW route already tried to expose coordinates (getattr(facility.location, "latitude"/"longitude", None)) — but Location has no such attributes, so it was always None. This makes that latent intent actually work.

Changes

• Coordinates value object + parse_decimal_degrees() helper + Location.coordinates() accessor — the one place that parses the OKW spec's decimal-degrees gps_coordinates string. Returns None if absent, not a "lat, lon" pair, or out of latitude/longitude range.
• Location.to_dict() now emits a structured "coordinates": {lat, lon} alongside the raw spec string, so OKW search/detail responses carry numeric coordinates.
• Refactored to_spaceapi_json() (MoM bridge) to use the accessor — removes the duplicated ad-hoc split/try-except.
• Fixed the OKW route's dead coordinates branch (read a non-existent location.latitude/longitude); now uses the accessor.
• Unit tests: parser (valid / whitespace / malformed / out-of-range / absent), to_dict emission, and the SpaceAPI path sharing the accessor.

Design notes

• gps_coordinates stays the spec-compliant stored form (OKW §6.3, Decimal Degrees) — this adds a derived typed view, no data migration (per the agreed approach).
• Two larger OKW cohesion issues found during review are intentionally deferred to their own focused tasks (recorded in the planning backlog): the Location vs Address city/region/country redundancy (non-spec, has match-filter blast radius), and the from_dict/to_dict round-trip asymmetry.

Verification

make ready — all gates green (553 passed, parity 4/4, docs ✓).

Next: the dashboard rework (map hero + network stats + getting-started) lands on frontend-dev and consumes location.coordinates.

🤖 Generated with Claude Code