The first-pass JSON-decode hardening exposed two latent bugs that the
fuzz scenario hits as soon as the WS handler stays alive past a bad
message:
1) `data.get("type")` is called on whatever `receive_json()` decodes,
but valid JSON can be a list/string/number, not just a dict. Reject
non-object payloads with a structured bad_message error before
dispatch.
2) `submit_answer` did `if answer not in {"A","B","C","D"}` which
raises TypeError when the client sends an unhashable answer
(e.g. a dict). Add an isinstance(str) guard so any non-string
answer falls into the bad_answer branch instead of crashing the
handler.
31/31 pytest still passes. Together with the prior commit, the WS
handlers now survive the full set of fuzz payloads without dropping
the connection.
A single malformed JSON message (or a "WebSocket is not connected" race
on disconnect) was killing the per-client handler with an uncaught
exception in the ASGI app. The surrounding try/except only caught
WebSocketDisconnect, so the server would log a stack trace and the
client would silently drop.
Wrap receive_json() to catch JSONDecodeError, send a structured
{"type":"error","code":"bad_message"} ack, and continue. Widen the
outer except to (WebSocketDisconnect, RuntimeError) so disconnect
races on send/receive after close exit the handler cleanly instead
of bubbling up the ASGI stack.
Both student_ws and instructor_ws hardened in parallel. 31/31 pytest
suite still passes; this fixes the recurring fuzz-scenario warn and
the cycle-187-style cascade observed in the stress loop.
