fix: unsubscribe shadow topics so reconnects release the connection graph

[mabrews]

Summary

Stacked on dahlb#75 — this diff is just the second fix; base it on main once dahlb#75 merges.

ShadowClientSubscriberMixin.__init__ subscribes to two AWS IoT shadow topics per
device and only logged the returned unsubscribe handles, never storing or calling
them. There was no unsubscribe() anywhere in the library.

awscrt holds a reference from native code to each subscription callback, and both
callbacks close over self. Python's garbage collector can't see those references,
so the device, its shadow client, and the TLS context and MQTT buffers underneath
stayed alive even after disconnect() closed the socket and every Python caller
had dropped its reference.

Callers that rebuild the connection therefore strand one full connection graph per
rebuild. ha_hatch rebuilds hourly, on AWS credential expiry, so a long-running
Home Assistant instance accumulates one per hour for the life of the process —
confirmed via HA's built-in memory profiler: 140 live RestIot objects after 137
hours of uptime, an exact 1:1 with the reconnect count, costing roughly 28 MB/day
on top of the thread leak fixed in dahlb#75.

Fix: record the topics returned from each subscribe call, and add unsubscribe()
to release them. Tolerant of an already-dead connection — the UNSUBACK never
arrives, but tearing the connection down releases the same native references, so
the topics are cleared either way.

A companion ha_hatch PR calls this from the coordinator's teardown path, before
disconnecting.

Test plan

• 4 new tests: topics are retained on subscribe, unsubscribe() releases all of
  them, it's idempotent (the coordinator can call it from both the reconnect and
  shutdown paths), and it still clears state when the connection is already dead.
  All 4 fail against the pre-fix code (AttributeError: no attribute 'unsubscribe').
• Full suite passes: 32/32.
• Deployed to my own Home Assistant alongside fix: reuse a shared awscrt ClientBootstrap to stop event loop thread leak dahlb/hatch_rest_api#75 and soaked for 72 hours
  continuous uptime. Measuring the identical 40-64h uptime window the fix: reuse a shared awscrt ClientBootstrap to stop event loop thread leak dahlb/hatch_rest_api#75-only
  soak used (for a direct comparison): memory growth dropped from +33.3 MB/day to
  +0.7 MB/day, effectively flat. Zero shadow unsubscribe failed log entries
  across the whole run.

[mabrews]

Opening this against dahlb/hatch_rest_api directly instead — this fork-internal PR doesn't reach the upstream maintainer.