web: fix topology device markers placed in the water

[armcconnell]

Resolves: #652

Summary of Changes

• Fix device markers on the topology map and globe that were rendered in the ocean. They were positioned as a metro centroid plus a fixed 0.3° (~25 mi) radial fanout, ignoring real device locations; for coastal metros like NYC that arc placed markers offshore in the Atlantic and the harbor.
• Default to a much tighter metro-centroid fanout (radius 0.3° → 0.04°, ~3 mi) so co-located devices stay visually separated without landing in the water.
• Add a "Precise locations" toggle (available on both map and globe) that anchors each device at its real facility coordinates, with a small jitter (~0.5 mi) so devices sharing a facility remain individually clickable. Devices with no facility coordinates fall back to the fanout.
• Extract the duplicated calculateDevicePosition from the map and globe into one shared, unit-tested helper (computeDevicePositions).
• Expose per-device facility latitude/longitude from the topology API (LEFT JOIN dz_facilities_current via location_pk).

The graph view is non-geo (force-directed), so it is unaffected.

Diff Breakdown

Category	Files	Notes
Core logic	5	shared helper (new), map, globe, topology API handler, context toggle
Scaffolding	2	control-bar toggle, api.ts type
Tests	1	devicePositions.test.ts (new)

Most of the change is the shared positioning helper plus wiring; the rest is the toggle and the API field.

Key files (click to expand)

• web/src/components/topology/devicePositions.ts — new pure helper: fanout (default, tight radius) + facility-anchored (with co-located jitter) + fallback
• web/src/components/topology-map.tsx / topology-globe.tsx — use the shared helper, keyed off the toggle; removed the duplicated local functions
• web/src/components/topology/TopologyContext.tsx — new preciseLocations overlay toggle (URL-synced like other overlays)
• web/src/components/topology/TopologyControlBar.tsx — "Precise locations" control on map and globe
• api/handlers/topology.go — facility lat/lng on the topology Device

Testing Verification

• New unit tests for the positioning helper: lone device sits on the metro center; co-metro devices stay within the (small) fanout radius and remain distinct; facility mode anchors a lone device exactly on its facility coords; co-located devices jitter within the facility radius and stay distinct; a device with no facility coords falls back to the metro fanout rather than [0,0].
• Full web unit suite passes (185 tests).
• Verified against production data that all 97 activated devices have facility coordinates (so facility mode resolves real locations rather than falling back), and that up to 4 devices share a facility (hence the co-located jitter).

[ben-dz]

One robustness gap to fix before merge; otherwise a clean, well-tested fix.

High — api/handlers/topology.go:250: the new LEFT JOIN dz_facilities_current f ON d.location_pk = f.pk lacks the isUnknownIdentifierError fallback that every sibling handler already has for this exact column (devices.go:204-217, facilities.go:202/:290, metros.go:246). d.location_pk isn't guaranteed present in all environments (e.g. remote proxy tables predating the migration). The query runs unguarded inside an errgroup goroutine, so on such an environment FetchTopologyData fails wholesale and /api/topology returns 500 — taking down map, globe, and the non-geo graph — while the devices/facilities pages on the same deployment keep working via their fallback. Fix: on isUnknownIdentifierError, retry with the join removed and 0 as latitude, 0 as longitude (frontend already treats 0/0 as no-coords and falls back to the metro fanout).

Low: device query has no ORDER BY, so fanout/facility-jitter ring slots (assigned by array index) can swap between refetches; sort each group by pk for stable placement.

Security review found nothing: static SQL (no interpolation, no user input into FetchTopologyData), endpoint gating unchanged, facility lat/lng already public via /api/dz/facilities, URL overlay param parsed against a fixed key whitelist.

[ben-dz]

The new LEFT JOIN dz_facilities_current f ON d.location_pk = f.pk references d.location_pk, which is not guaranteed present in every environment the API serves (e.g. remote proxy tables created before the location_pk migration). Every sibling handler that touches this column guards against its absence: devices.go:204-217 builds a fallback query stripping the identical join and retries on isUnknownIdentifierError (ClickHouse code 47); facilities.go:202/:290 and metros.go:246 do the same.

This query runs unguarded inside an errgroup goroutine, so on an environment lacking location_pk the error fails FetchTopologyData wholesale and /api/topology returns 500 — taking down map, globe, and the non-geo graph — while the devices/facilities pages on the same deployment keep working via their fallback.

Fix: mirror the sibling pattern — on isUnknownIdentifierError, retry with the join removed and 0 as latitude, 0 as longitude (the frontend already treats 0/0 as "no facility coords" and falls back to the metro fanout, so it degrades cleanly).

[ben-dz]

The device query has no ORDER BY, so ClickHouse row order isn't stable across refetches, and both fanoutByMetro (here) and the facility-jitter loop (line 102) assign ring slots by array index. Markers within a fanout ring or co-located facility cluster can swap positions between page loads. Pre-existing for fanout; this PR extends it to facility jitter. Sort each group by pk before forEach for stable placement.