Cameras: fall back to TPAP on -40211 and work without the in-band discover - #11

This makes the camera path of the branch work against a real camera on the new firmware, a Tapo C510W 2.0 (fw 1.3.4 Build 260523). Three things were in the way:

1. The in-band discover is refused. The camera answers {"sub_method":"discover"} with -40209, so TpapEncryptionSession._discover() raised before any login. Cameras announce TPAP in the UDP discovery instead (encrypt_type: ["4"] plus tpap: {pake: [2], tls: 1, noc: 1, port: 443}), so for the camera families the session now falls back to those values when the in-band discover fails or has no tpap object: password login, TLS on the management port, no DAC. Other families keep raising as before.
2. Default port. With https set the transport defaulted to 4433; cameras listen on 443.
3. Getting there from discovery. UDP discovery still reports encrypt_info.sym_schm: "AES" for these cameras. I did not want to route every camera that advertises ["4"] to TPAP, because the C101 fw 1.4.3 fixture in the repo advertises exactly that and was captured over the AES login, and my own C510W accepts the AES login again once Third-Party Compatibility is switched on in the Tapo app. So instead SslAesTransport now attaches the error code to the handshake1 failure, -40211 gets a name (MISSING_NECESSARY_PARAMS, the name the Tapo app uses), and _connect retries a camera over SmartCamProtocol + TpapTransport when the AES login fails with that code, updating config.connection_type.encryption_type so Home Assistant stores the new transport. Any other authentication error is raised as before.

Live result on the C510W (DeviceConfig with SMART.IPCAMERA, TPAP, https=True, user admin, TP-Link account password): handshake in 5 s (about 4 of them spent on the refused in-band discover), update() returns the model, firmware, 9 modules and 15 features (motion / person / tamper detection, LED, pan/tilt, RSSI, device time), and a second update() on the same session works. The -40211 switch itself is covered by unit tests only: my camera no longer refuses the AES login since compatibility mode is on, so if someone in the linked Home Assistant threads still gets -40211, that is the case worth trying.

Tests: 3596 pass locally, new ones cover the discover fallback (refused and missing tpap object), the camera default port, the handshake1 error code, and the _connect fallback (taken on -40211, not taken on other auth errors). Ruff and mypy are clean on the touched files.

The protocol details behind this (login, /ds framing, error codes) are written up at https://github.com/freeKC/tapo-v4-protocol in case that helps the review.