🛠 - Security hardening for `bbx_net` WebSocket server

[maxwellmattryan]

Description

The bbx_net WebSocket server has several security gaps that make it unsuitable for direct internet exposure (e.g., Raspberry Pi with DNS routing to allow remote access).

Critical Issues

Issue	Location	Impact
No TLS/SSL encryption	websocket/server.rs	All traffic readable over network
No rate limiting on room join	room.rs	Brute force attack on 6-digit codes (~1M attempts)
No message size validation	server.rs:201	DoS via large JSON messages
Unbounded connections	server.rs	Resource exhaustion attack

Medium Issues

• No parameter range validation (parser.rs)
• No source IP validation
• Stale connection cleanup never called (cleanup_expired() exists but unused)
• Predictable room code generation (XorShiftRng seeded with SystemTime)
• Room enumeration via error messages (INVALID_ROOM vs ROOM_FULL reveals valid codes)
• Float parameters accept NaN/Infinity values that propagate to DSP engine

Note: OSC uses UDP with zero authentication and should stay LAN-only or VPN-tunneled.

Open Questions

• Should TLS be required or optional (feature flag)?
• Default room code length: 8 alphanumeric vs longer?
• Should rate limiting config be runtime or compile-time?

Acceptance Criteria

• WebSocket messages have size limit (default 4KB)
• Global and per-IP connection limits enforced
• Room join attempts are rate-limited per IP
• Room codes use CSPRNG and are 8+ alphanumeric characters
• Background task cleans up stale connections/rooms
• Optional TLS support via feature flag
• TypeScript client error codes synced
• Deployment documentation with reverse proxy examples
• Error messages don't distinguish between invalid and valid-but-full rooms
• Float parameter values validated (reject NaN, Infinity, extreme values)

Tasks

TBD