WS recv loop swallows all exceptions with broad `except Exception: continue`

[TexasCoding]

From Wave 5 — N-07, O-04, P-12 all flag the same code. Severity: medium.

Code

kalshi/ws/client.py:204-207:

except Exception as e:
    logger.warning("Error processing message: %s", e)
    continue

What gets silently swallowed

• KalshiBackpressureError from a full queue with OverflowStrategy.ERROR — defeats the entire point of the ERROR strategy (the consumer never sees the signal that they're falling behind).
• KalshiSequenceGapError — defeats the docstring claim that gaps surface to callers.
• Pydantic ValidationError from the dispatcher's typed parsing — bugs in message models go silent.
• Programming errors in user-registered callbacks — debugging painful, no traceback.
• KeyError, AttributeError, anything else not ConnectionClosed or CancelledError.

logger.warning(...) doesn't pass exc_info=True, so users see "Error processing message: KeyError: 'sid'" with no stack trace. A repeating callback bug logs hundreds of warnings without indicating where they came from.

Fix

Narrow the catch:

• Re-raise (or break the loop, push sentinels, exit cleanly): KalshiBackpressureError, KalshiSubscriptionError, asyncio.CancelledError.
• Log + continue only for the genuinely-non-fatal classes: pydantic.ValidationError, json.JSONDecodeError, KeyError. Add exc_info=True so the traceback is visible.
• Optionally: add a consecutive-failure counter that breaks the loop after N to fail-fast on a corrupted server stream.

Note on documentation

This is the underlying cause of two behaviors already documented as "known caveats" in docs/websockets.md and docs/errors.md:

• KalshiBackpressureError is defined but not propagated.
• KalshiSequenceGapError is defined but not raised by the default loop.

Fixing this lets us delete those caveats.