Fix lightning map layer timestamps

[DigitalFeonix]

What does this PR do?

Primarily this updates the Lightning Map Layer to convert the nanosecond timestamp from Blitzortung, to a millisecond timestamp so it's consistent with the rest of the JS, After that it refactors some related code,

Type of change

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

How to test

1. Activate Lightning Layer
2. View the Lightning Activity panel and see numbers show up in the "Recent (<5 min)" section
3. Click the Lightning Strike indicators and see the Time label make sense

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)

Before

After

[accius]

Good catch — the timestamp handling was definitely broken. Blitzortung sends nanoseconds, so Date.now() - parseInt(data.time) was doing milliseconds minus nanoseconds, which produced nonsense. Converting to ms at ingest with data.time / 1000000 and computing age at render time is the right fix. Removing the stale age property is also correct since it was computed once at ingest and never updated.

One question before I merge:

STRIKE_RETENTION_MS now ignores lowMemoryMode — this went from 1min/5min (conditional) to a flat 30 minutes for everyone. MAX_STRIKES still caps at 100 in low memory mode so it won't explode, but is the 30-minute window intentional? That's a 6x increase even for normal mode (was 5 min). Just want to confirm that's by design and not an accidental leftover.

Minor style nit (non-blocking): parseInt(data.time / 1000000) works but parseInt is really meant for string-to-int parsing. Math.floor(data.time / 1000000) is more idiomatic for numeric truncation.

Otherwise LGTM — nice fix.

[DigitalFeonix]

Just to close the loop then.

STRIKE_RETENTION_MS now ignores lowMemoryMode — this went from 1min/5min (conditional) to a flat 30 minutes for everyone. MAX_STRIKES still caps at 100 in low memory mode so it won't explode, but is the 30-minute window intentional? That's a 6x increase even for normal mode (was 5 min). Just want to confirm that's by design and not an accidental leftover.

Yes, that was intentional as mentioned in the commit message body. The recent activity panel goes to 30 minutes, so this was to match the panel. As the amount of items in the array is more important than their time to control memory bloat, I left the item count trim alone, and adjusted the time to 30 minutes to match the panel.

Minor style nit (non-blocking): parseInt(data.time / 1000000) works but parseInt is really meant for string-to-int parsing. Math.floor(data.time / 1000000) is more idiomatic for numeric truncation.

In that case, Math.floor( parseInt(date.time) / 1000000) would have been more appropriate. I would have made that change to the PR if I had been able to respond before you merged.