Issue: WebSocket error handling is brittle and silently failing in useDebateWS

### Problem

The WebSocket message handler in `frontend/src/hooks/useDebateWS.ts` had brittle error handling and previously contained empty `catch` blocks, which could silently swallow failures. This made debugging difficult and degraded user experience during connectivity issues.

Beyond the empty catch block, the existing implementation also had several reliability gaps, including:

* Silent failure modes during message parsing
* Potential console spamming on repeated failures
* Unclear reconnection behavior
* No distinction between normal vs abnormal WebSocket closure
* Risky cleanup logic on component unmount
* No protection against malformed or empty messages

---

### Expected Behavior

WebSocket failures should:

* Be clearly logged with meaningful context
* Avoid flooding logs or UI with repeated errors
* Attempt reconnection with controlled backoff
* Treat normal WebSocket closure (code 1000) as non-error
* Clean up safely when the component unmounts
* Gracefully handle malformed or empty messages

---

### Proposed Fix

Refactor **`useDebateWS.ts`** to include:

* Centralized `handleError` with throttling
* Exponential backoff retry logic with a maximum cap
* Clear handling of normal vs abnormal closures
* Defensive message parsing (reject empty messages)
* Safer WebSocket cleanup using `try/finally`
* Reset of error state on successful messages
* Automatic reconnection attempts on failure

---

### File Affected

* `frontend/src/hooks/useDebateWS.ts`

Start by reading frontend/src/hooks/useDebateWS.ts and trace the WebSocket message, error, closure, reconnection, and unmount-cleanup paths. Compare each path with the expected behavior in the issue, including malformed or empty messages and normal closure code 1000. Done means failures are contextual and controlled, reconnection uses capped backoff, cleanup is safe, and successful messages reset error state.

Written by the indexing model from the issue text.