feat(mcp): expose static geospatial reference registries (military bases, ports, AI datacenters, trade routes) as query tools

## Summary

We maintain rich curated geospatial reference registries, but only two are queryable by agents (`get_commodity_geo` for mines, `get_chokepoint_status` for the chokepoint registry). The rest render on the map and are invisible to the MCP/REST surface:

| Registry | Existing data |
|---|---|
| Military bases (120+ across operators) | `src/config/military-bases.ts`, `src/config/bases-expanded.ts` |
| Strategic ports | `src/config/ports.ts` |
| AI datacenter clusters | `src/config/ai-datacenters.ts` |
| Trade routes | `src/config/trade-routes.ts` |
| Airports | `src/config/airports.ts` |
| Irradiator / nuclear-relevant sites | `src/config/irradiators.ts` |
| Bypass corridors | `src/config/bypass-corridors.ts` |

Two registries to add/complete while in here:

- **Nuclear facilities** — power plants, enrichment, reprocessing sites (Zaporizhzhia, Natanz, Fordow, Yongbyon…). We have a nuclear map layer and `irradiators.ts`; consolidate/curate into one queryable registry.
- **Undersea cable routes** — landing points, owners, capacity. `src/services/cable-health.ts` scores 6 corridors; the underlying route/landing-point registry should be queryable too (curate if we only hold corridor geometry today).

Lower-priority registries — same tool, curate cheaply or explicitly wontfix each with a reason (do not silently drop):

- [ ] Spaceports / launch facilities
- [ ] Stock exchanges (tiered, with index tickers)
- [ ] GFCI financial centers
- [ ] Cloud provider regions

"Which Chinese-operated bases are within 500 km of Djibouti?" or "list AI datacenters above 100 MW in the Gulf" are exactly the queries agents ask and we already hold the answer.

## Proposed scope

1. One consolidated MCP tool (e.g. `get_reference_geo`) with a `registry` param + per-registry filters (operator, country, type, bbox/radius), rather than N thin tools — mirrors how `get_commodity_geo` works today.
2. Serve from the static configs (build-time bundle into the server, or a generated JSON artifact) — no seeder needed; freshness metadata marked as `static/curated` with a data-vintage field.
3. Cross-link entries to live layers where natural (e.g. base → current military flights nearby is future work, not this issue).

## Out of scope

- Pipelines and storage facilities — REST ops `list-pipelines` / `get-pipeline-detail` / `list-storage-facilities` already exist and their MCP exposure is tracked in #4525.
- Any new data collection; this exposes what `src/config/` already curates.

## Acceptance criteria

- [ ] Registries queryable via MCP with filters, schema, tests, docs, parity entries.
- [ ] Single source of truth: map layers and MCP serve the same config modules (no copied datasets).
- [ ] Data-vintage/curation caveat present in tool output and docs.

Start by tracing the existing get_commodity_geo and get_chokepoint_status tools, then inspect the registry modules under src/config/ and the cable context in src/services/cable-health.ts. Define the consolidated registry and filter scope before implementing, including the unresolved lower-priority registries. Done means MCP queries, schema, tests, docs, parity entries, shared config sources, and data-vintage caveats meet the acceptance criteria.

Written by the indexing model from the issue text.