[Bug 898] UDP (local) spots can show an incorrect location of the spotter

[alanhargreaves]

What does this PR do?

When using Local UDP for a DX Cluster source, some programs do not list a lat/lon or grid square. When this happens, s.spotterGrid is set to null and the hooks code tries to find teh location based purely on teh callsign prefix, which can be preoblematical.

This fix uses CONFIG.gridSquare instead of just defaulting to null if no gridSquare is offered.

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

How to test

1. If using Local UDP for DX Cluster, curl localhost:3000/api/dxcluster/paths
2. Verify that the spotterGrid is set to the local gris square

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

[accius]

Review — UDP spotter location fallback (draft)

Minimal, targeted fix. The one-line change is sensible for the local-UDP case: the "spotter" in a local UDP feed is effectively the operator themselves, so falling back to the server's CONFIG.gridSquare (which in self-hosting mode = the operator's grid) is reasonable when the upstream program doesn't supply one.

Concerns / questions

1. CONFIG.gridSquare semantics in a multi-tenant deployment. On the public server at openhamclock.com, CONFIG.gridSquare is the server operator's grid, not the individual user's — if this code path is ever reached in the hosted deployment, we'd be tagging every UDP spot with the server's location. Can you confirm this udpSession code path is only hit in self-hosted mode? If there's any chance it runs for hosted users, please guard with an isLocal / isSelfHosted check or pass the user's own grid in via the session.

2. CONFIG in scope: please double-check that CONFIG is imported/available at the top of this route, and that CONFIG.gridSquare is the field name (vs CONFIG.locator — the frontend config uses locator). A grep for other CONFIG.gridSquare references in server/ would be reassuring.

3. Nit: consider falling back to CONFIG.locator if CONFIG.gridSquare isn't set — same source, different name on the frontend config, and either could be the canonical field depending on how the server reads the user's config.

4. PR description typos ("teh", "preoblematical", "gris") — tidy up before marking ready.

Happy to re-review when out of draft.