Any time we use pass a callsign over http we need to encodeURIComponent()

[alanhargreaves]

What does this PR do?

Any time we pass a callsign to the server API in useRBN.js we need to encode the callsign so callsigns with suffixes like /P don't screw things up.

Type of change

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

How to test

Watch an RBN skimmer for a known CW op operating with a suffix like /P that has also spotted in either DX Cluster or an ActivatorPanel type spot and verify that we get the proper location.

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

[alanhargreaves]

I'm running this locally to verify that it addresses the issue. If to this evening, I expect to see VK2IO/P activating in the morning on CW.

[alanhargreaves]

ok it looks like /api/callsign does not check our caches. It probably should.

[accius]

Correct fix. Line 280 was the only callsign-bearing fetch in this file still interpolating raw, the user-callsign spots fetch at line 244 already runs through encodeURIComponent, so this brings the location lookup in line with it. A skimmer callsign with a / portable suffix would otherwise break the path segment.

One thing: this is still marked draft. Flip it to ready when you are happy with it and it can go in.

K0CJH

[accius]

@alanhargreaves checking in on this one — the fix itself is plainly correct (portable suffixes like VK2IO/P break the unencoded path segment) and CI is green. Did your morning VK2IO/P test pan out? If so, feel free to mark it ready for review and we'll get it merged.

Your side-observation about /api/callsign not checking our caches was a good catch — I've split it out into its own issue so it doesn't get lost here.