[BUG 685] Add full multicast support for WSJT-X, so that multiple apps can listen

[alanhargreaves]

What does this PR do?

As per #685, add support for configurations having wsjt-x use multicast for reporting.

In the majority of cases listening on port 2237 with address 0.0.0.0 works just fine. Problems arise when we have more than one application listening for the packets. In this case all applications need to properly configure themselves for multicast use.

If you have more than one application wanting to receive the wsjt-x packets via multicast, you will need to configure WSJTX_MULTICAST_ADDRESS in .env and restart; ensuring that you use the same address that wsjt-x is configured to multicast to (e.g. 224.0.0.1)

Type of change

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

How to test

1. Uncomment the WSJTX_MULTICAST_ADDRESS entry in .env, ensuring it matches what wsjt-x is using
2. Restart the server
3. Note that we get a server log message stating that we are listening on multicast ```
   [WSJT-X] UDP listener on 0.0.0.0:2237
   [WSJT-X] Joined multicast group 224.0.0.1

5. Verify that packets are coming in by either watching the WSJXT panel or running ```
$ curl localhost:3000/api/wsjtx/decodes

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