[satellites] update satellites tracked

[MichaelWheeley]

What does this PR do?

• update satellites tracked list, ref/thank @creinemann
• added #41866 GOES-16 celestrak_weather
• added #55506 ELEKTRO-L4 celestrak_active
• added #67756 ELEKTRO-L5 celestrak_active
• removed #53106(payload) = #53109(rocket body) = IO-117(Greencube), satellite decommissioned
• for all entries adds data_source field with CelesTrak group data source

Type of change

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

How to test

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]

Thanks for keeping the satellite registry current, and thanks to @creinemann for the source list.

Reviewed the diff — this is a clean, data-only update to server/routes/satellites-tracked.js:

• Adding GOES-16 (#41866) and ELEKTRO-L4/L5 (#55506/#67756) looks correct, and dropping IO-117/GreenCube on decommissioning is the right call.
• Converting the trailing // CelesTrak group: ... comments into a real data_source field is a nice improvement — self-documenting and queryable rather than buried in a comment.

Two small notes, neither blocking:

1. data_source is currently informational only. The TLE fetch in satellites.js hardcodes groups = ['amateur', 'weather', 'goes'] and matches purely by NORAD ID. The celestrak_active entries (QMR-KWT-2, ELEKTRO-L3/L4/L5) aren't in those group files, so they resolve via the per-NORAD CATNR fallback. That path already works for the existing active sats, so the new ones will resolve the same way — just flagging that the field doesn't yet drive fetch behavior in case a future change wants to wire it up.
2. GOES-16 and the new ELEKTRO entries omit mode/frequency. The merge logic in satellites.js handles missing optional fields gracefully (||/??), so this is fine, but adding HRIT/LRIT mode + downlink frequency for the ELEKTRO sats (consistent with L2/L3) would round out the metadata if you have it handy.

CI is green and the branch merges cleanly into Staging. Looks good to me.

— K0CJH

[MichaelWheeley]

@accius you said,

1. data_source is currently informational only......

actually the 'data_source' field is utilized in the change to the satellites.js in #1007

2. GOES-16 and the new ELEKTRO entries omit mode/frequency........

(my personal opinion only) is that the extra information is difficult to accurately maintain unless it is constantly being reviewed and updated, and could be dropped completely focusing OHC solely on location tracking and prediction

[accius]

@MichaelWheeley — fair points, thanks for the follow-up.

On data_source: you're right. #1007's state machine filters HAM_SATELLITES by data_source (celestrak_amateur / celestrak_weather, and startsWith('celestrak') for the per-NORAD path) to route group vs. individual fetches. My note was scoped to #1004 in isolation, where the field genuinely was inert — #1007 is what makes it load-bearing. The two PRs are a pair. (Related: in the #1007 review I flagged that startsWith('celestrak') needs a ?. guard, since this file's own header says data_source may be absent.)

On dropping mode/frequency: I understand the maintenance concern — hand-curated frequency tables do go stale. But I'd rather automate it than drop it, since downlink/mode is genuinely useful to operators (it's what the satellite popup shows). The SatNOGS Transmitter database is built for exactly this — crowd-maintained, machine-readable uplink/downlink/mode/baud/status keyed by NORAD ID: https://db.satnogs.org/api/transmitters/. Note this is a different dataset from the SatNOGS TLE feed you (correctly) dropped in #1007 — orbital data there is questionable, but transmitter data is SatNOGS's core strength.

The plan: a background fetcher — same state-machine pattern as #1007 — refreshed daily, joined by NORAD ID, with the curated values in satellites-tracked.js kept only as a fallback for sats SatNOGS doesn't cover (some geostationary weather birds may not have transmitter entries). That removes the manual upkeep you're worried about while keeping the data. I'll spec it as a follow-up.

Appreciate you pushing on this.

— K0CJH