[performance] Satellite - use filters, only calculate selected satellites

[MichaelWheeley]

What does this PR do?

• refactors satellite filters,
• passes filters to useSatellites.js and enables calculations only for those selected

Type of change

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

How to test

1. enable all satellites, confirm all satellites appear, choose at least one to confirm satellite details window is functional
2. browser devtools -> Performance add 4xCPU throttling
3. compare none vs all satellites selected

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

Screenshots (if visual change)

[accius]

Perf win here is real and the gating idea is right, but a couple things worth a look before this goes in.

1. There's a Rules-of-Hooks violation in useSatellitesFilters.js:

export default function useSatellitesFilters(satellitesData, externalState) {
  const state = externalState || useSatelliteFilterState();

useSatelliteFilterState is a hook, so calling it conditionally based on whether externalState is truthy breaks the "hooks must be called in the same order every render" rule. In this PR App.jsx always passes externalState, so at runtime it happens to work, but the lint rule will flag it, and if anyone ever calls useSatellitesFilters(data) without state (the old signature) the hook ordering breaks between renders.

Cleanest fix is to drop the fallback and require externalState since App.jsx is the only caller now. Or split into two genuinely separate hooks (one owns the state, one is pure-filter) and let the caller wire them together.

2. The default param on useSatellites:

export const useSatellites = (observerLocation, satelliteConfig, filteredNames = []) => {

combined with the isCalcNeeded gate means if anyone calls this without a filteredNames arg, every satellite gets skipped (the empty array's .includes is always false). Today only App.jsx calls it so it's fine, but the default value is doing the opposite of what a "safe default" should do. Maybe default to null and treat null as "no filter, calculate all" so the old behavior is preserved if a caller forgets to pass it.

3. Smaller question on the placeholders: when a satellite is filtered out you push a zeroed object (lat: 0, lon: 0, track: [], footprintRadius: 0, isVisible: false) instead of just not pushing. Does the satellite list panel, popup, or footprint rendering treat a zeroed sat any differently from an absent one? Probably fine since isVisible: false should gate most of it, but worth a quick sanity check before merge.

Otherwise structure is clean. The 60 * 60 * 1000 readability swap is nice too.

[accius]

Will look more at this when I land and am home, day got away from me and haven't reviewed the auto triage yet.

All three review items addressed in the latest push. Hook violation fixed (now throws if externalState missing), default param changed to null so a missing filter calculates everything, and the zeroed-placeholder problem replaced with a name-only stub plus defensive Number.isFinite / safeNum / safeStr / safeArr guards across useSatelliteLayer.js. Unblocking the merge gate.