Bump to 0.0.17 and add its release notes

The release workflow validates the tag against manifest.json and prefers
release_notes/<version>.md over generated notes, so both have to be in
place on the commit being tagged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LLPEGFSy3fLEuXNUPAPWR4

Author: claude

custom_components/cellar_tracker/manifest.json

@@ -15,5 +15,5 @@
   "requirements": [
     "cellartracker==1.1.1"
   ],
-  "version": "0.0.16"
+  "version": "0.0.17"
 }

release_notes/0.0.17.md

@@ -0,0 +1,44 @@
+## A hung CellarTracker no longer ties up Home Assistant
+
+The `cellartracker` library fetches your inventory with `requests.get()` and sets no timeout, so the socket had no deadline. Home Assistant stopped *waiting* after 60 seconds, but the worker thread doing the fetch could not be interrupted: against a server that accepts a connection and then never replies, it stayed parked until the operating system gave up — by default two hours — holding your account password in its stack frame the whole time. Repeated polls stacked up more of them.
+
+The inventory is now fetched with Home Assistant's own shared `aiohttp` session under a 60-second `asyncio.timeout`, so a stalled request is genuinely cancelled and no thread is involved. Parsing still runs off the event loop, because 66 columns per bottle is real work.
+
+This covers **setup and re-authentication too**, not just background polling — the paths where you are watching a spinner. A CellarTracker that never answers now fails as "Failed to connect" in about a second instead of hanging the dialog.
+
+Nothing about your credentials, entities or history changes.
+
+## ⚠️ One CellarTracker account per installation
+
+Adding a second account now stops with:
+
+> CellarTracker is already configured. Only one account is supported per Home Assistant installation.
+
+Previously the uniqueness check was keyed on the username, so a second entry naming a different account was accepted — and the integration carried a good deal of machinery to cope with the resulting ambiguity, including API responses that refused to answer until you told them which account you meant.
+
+**Already running two accounts?** Nothing breaks. Both entries keep loading, and `?entry_id=` on your dashboard URL still selects between them:
+
+```yaml
+type: iframe
+url: /cellartracker/cellar.html?entry_id=YOUR_ENTRY_ID
+aspect_ratio: 100%
+title: My Wine Collection
+```
+
+A card with no `entry_id` gets the first account, and a warning naming the others is logged. You cannot add a *third*.
+
+Running one account, as almost everyone is? Nothing to do. A leftover `?entry_id=` on an old card URL is accepted and ignored, so existing cards keep working unedited.
+
+## Fixes
+
+* The REST endpoints no longer ignored `?entry_id=` on an installation that still had two accounts, which served the first account's bottles priced in the second account's currency, with no error. Both the API and the bundled dashboard honour the parameter again.
+* Credential validation went through the library's blocking client even after the coordinator had stopped doing so, leaving setup and reauth exposed to the timeout problem above. Both paths now share one fetch, so they cannot drift apart on transport or on what counts as an authentication failure.
+* `loggers: ["cellartracker"]` dropped from the manifest — it named a logger in library code the integration no longer calls, so it could never emit anything.
+
+## Under the hood
+
+The test suite is 190 tests, up from 159, including a new suite that runs the dashboard's real JavaScript under node rather than asserting on its source text.
+
+The README's "Known limitation" section, which described the timeout as outstanding, now records why the library's transport is bypassed and notes the one-line upstream fix that would make that unnecessary.
+
+**Full Changelog**: https://github.com/GuvHas/cellartracker/compare/0.0.16...0.0.17