Verify TLS on the AWS IoT HTTP calls

[OdynBrouwer]

Fixes #156

Every request the AWS IoT backend made passed ssl=False to aiohttp: visitor authentication (which returns the bearer token), QR binding, device discovery, state polling, and the v2 control command. That switches certificate validation off, so tokens and spa control traffic could be read or rewritten by anyone able to intercept TLS - hostile Wi-Fi, a compromised router.

The other two backends verify normally, and this backend's own WebSocket client already uses Home Assistant's SSL context. aiohttp does not disable verification by default either, so the only thing ssl=False achieved here was removing a protection: this was a leftover from developing against the endpoint, not a decision.

All five call sites now use the session's default, verified TLS behaviour. No test pinned ssl=False, and the new tests hold the line: two drive _do_get() and _do_post() and assert no ssl argument reaches the session, and a third scans the module for ssl=False, which also covers the credential-bearing and encrypted call sites (authenticate, bind_qr_code, the v2 command) that a unit test would need half a request pipeline to drive.

Verified live against all three regional endpoints - EU, US and CN - with Home Assistant's SSL context and with a stock ssl.create_default_context(): each presents a certificate whose common name matches the host, issued by Amazon, valid until March 2027. A plain GET returns 404 rather than a TLS error, which is the point: the handshake and the verification succeed, so removing ssl=False cannot break existing installs. That manual check is the one the issue asked for, since the suite cannot answer it.

Verified

Removing ssl=False is only safe if the gateway presents a certificate default validation accepts, and the test suite cannot answer that - so I checked it live against all three regional endpoints, with Home Assistant's SSL context and with a stock ssl.create_default_context():

endpoint	result	certificate
EU smarthub-eu.bestwaycorp.com	OK (404 on /)	common name matches the host, issuer Amazon, valid until Mar 2027
US smarthub-us.bestwaycorp.com	OK	common name matches the host, issuer Amazon, valid until Mar 2027
CN smarthub.bestwaycorp.cn	OK	common name matches the host, issuer Amazon, valid until Mar 2027

A plain GET to / is enough: getting any HTTP status back means the handshake and the verification succeeded, where an untrusted or mismatched certificate would have failed first.

Also ran locally before opening: the full suite (292 tests) and the complete pre-commit gate.

I could not exercise the authenticated calls themselves - I have no valid visitor credentials - but TLS validation is a property of the endpoint rather than of the request, and all five call sites talk to those same three hosts.