Stop re-formatting the same stream exception on every read-loop iteration

[bvis]

Related to #23 and #33; complementary to #36 and #38 (different code path: this covers the generic "unexpected exception" branch that those PRs leave untouched).

Summary

When the MCS stream fails persistently, the _listen loop can re-format and log the same exception object on every iteration — and that exception's traceback grows on each raise, making the logging quadratically expensive inside the event loop.

Mechanism:

1. asyncio's StreamReader stores a failed stream's exception and re-raises the SAME object on every subsequent read (asyncio/streams.py, raise self._exception), appending a few frames to its __traceback__ each time.
2. A ConnectionResetError outside RESETTING state hits the generic else branch, which calls _logger.exception(...) — full traceback, every iteration.
3. If _reset() early-returns (its lock is held, e.g. by the monitor task), the loop re-reads the poisoned reader with no suspending await → tight loop.
4. On Python 3.13+ traceback formatting additionally runs ast.parse per frame (caret anchors), so formatting the growing chain dominates: observed in production as a CPU core pinned at 100% for >10 minutes inside the event loop.

Observed on a Home Assistant 2026.6.1 / Python 3.14 installation during a period when Google persistently reset the MCS session right after login: HA's event loop starved, the HTTP API died, and the OS watchdog kill-looped the process. py-spy dump of the hung process:

Thread 71 (active+gil)          ← MainThread / event loop
    parse (ast.py:46)
    _extract_caret_anchors_from_line_segment (traceback.py:842)
    format_frame_summary → format → print_exception
    formatException (logging/__init__.py:670)
    ...
    _listen (firebase_messaging/fcmpushclient.py:717)

Changes

• Track the last exception seen by the read loop by identity. The first occurrence keeps today's behaviour (full logging.exception). Repeats of the same object are summarised through the existing _log_warn_with_limit helper (one line, no traceback) and the loop await asyncio.sleep(1)s so it can never spin hot on a poisoned reader. Error accounting (_try_increment_error_count / _reset) is unchanged in both paths.
• tests/fakes.py: FakeReader.set_exception() mimics StreamReader's sticky-exception semantics so the failure mode is reproducible in tests.
• Regression test asserting that with a persistently failing reader the full traceback is logged exactly once and the rate-limited summary line appears. The test fails on current main and passes with this change.

Testing

• uv run pytest tests/test_fcmpushclient.py — 14 passed (13 existing + 1 new).
• New test verified to fail without the fcmpushclient.py change.
• ruff check / ruff format --check clean.

[bvis]

Hi, is anything I could do?