map: ScriptProcessorNode audio fallback so listening works over plain HTTP

[M0LTE]

Problem

On the live map, clicking a port's ♪ to listen threw:

TypeError: Cannot read properties of undefined (reading 'addModule') at ensureAudioCtx (map:1575)

ensureAudioCtx calls ctx.audioWorklet.addModule(...), but AudioWorklet is a secure-context-only API. When the UI is served over plain HTTP from a non-localhost host (e.g. http://packetdotnet:8090), ctx.audioWorklet is undefined, so playback never started. (The ws:// audio stream itself isn't secure-context-gated — only the worklet playback was.)

Fix

Branch the playback node in ensureAudioCtx:

• Secure context (HTTPS / localhost): unchanged — AudioWorklet as before.
• Insecure context (plain HTTP): fall back to a ScriptProcessorNode. Deprecated and main-thread, but not secure-context-gated and fine for monitoring one port. Same queue/drain logic as the worklet, with a ~2 s backlog cap.

ws.onmessage now routes samples through a mode-agnostic listenState.feed, so both paths share the receive/decode code. No behaviour change on HTTPS/localhost.

Not in scope (separate, environmental)

The 503 on /api/peer/chatbot/state is unrelated: the peer proxy can't resolve a chatbot container on the Docker network (lookup chatbot ... no such host), so it returns a clean 503 and the map hides that panel. Nothing to fix in code — run a container named chatbot (port 8090) on the same network if you want the panel.

Testing

• make test green; go build of the embed OK; map.html JS passes node --check.
• Served /map over HTTP and confirmed it carries the fallback (createScriptProcessor, the ctx.audioWorklet guard, and the feed() routing).
• A true in-browser check over an insecure origin wasn't possible in the sandbox (host OS too new for Playwright's chromium; the chrome channel needs root). The fix targets the exact, confirmed cause with the canonical ScriptProcessorNode generator pattern — worth a 10-second manual confirm: reload the map over http://… and click ♪.

Merging publishes a fresh ghcr.io/packethacking/net-sim:main image with the fix.