feat(paths): Choose the negotiation path from the device's capability reply

[kb1ibt]

Last of four stacked PRs replacing #70; based on the negotiation PR. The device's capability reply (x803) now picks the key-establishment path, so a device the library doesn't speak fails fast with an error naming what it declared, and the older AES-only modules (#63) get their own path.

• Path registry (SolixBLE/protocols/session.py, PATHS = (EcdhPath, LegacyAesPath)): each path has matches(announcement, outer); the first that matches runs the rest of the negotiation. A path can depend on the outer, so legacy AES is offered only after a plain 0001 and is never reached by stepping down from 4001.
• ECDH matches a3 & 0x44 with an auth method in a5 (every current build), on either outer.
• Legacy AES matches a1 & 0x02 on the plain outer, e.g. the older a1 02 · a3 04 · no a5 reply in F3800 (A1790) fails encryption negotiation — device expects a newer key exchange (a5=02, 4022/4822/4023/4823) instead of 0021/0821 #63. 0005 states AES (a5 02); after 0805 00 the client keys CBC on its client id's first 16 bytes with the device serial's first 16 bytes as IV and sends 4022 (clock); 4822 returns 00 a1 10 <16-byte key>, which becomes the session key with the same IV; then 4023 binds the client (a2 client id, a3 serial), as the app sends it.
• Rejections: no matching path, an x805 status other than 00, an x821 without the device key, or an x822 without a key raise UnsupportedNegotiation (now exported), and connect() returns False at once, logging the declared values (base_method, encrypt_method, auth_method, mtu) and the stage. Before, such a device was answered with the ECDH steps regardless and ran into the negotiation timeout.
• Docs: protocols.rst "Paths" (the x803 table and how to add a path).

Legacy AES: the opening, the 0005, the initial key and IV, and the 4822 layout match the Anker app's own legacy sessions with an older Prime module, decrypted end to end. The switch to the 4822 key (IV unchanged) is how the device firmware installs it, and atc1441's Anker_Prime_BLE_hacking tool rekeys the same way; I have no device on that firmware, so the path after 4822 is untested on my own hardware. #63 F3800 owners: could you try F3800(ble_device) on this branch and post the debug log? The tests use synthetic values only.

Also: EcdhPath and LegacyAesPath share record_identity and send_clock from protocols/base.py; tests/helpers.py gains feed_negotiation.

Suite: 479 passed (base: 468). mypy --strict: 202 errors, unchanged from the base.

[kb1ibt]

Correction to the Legacy AES paragraph above: the path after 4822 has now been tested on hardware.

Since this was opened, LegacyAesPath runs on either outer (3cda650), so the body's "on the plain outer" / "offered only after a plain 0001" no longer hold. On the encrypted outer the path bootstraps on the static negotiation key and IV instead of the client id and serial.

I ran it end to end on a Prime Charging Station 240W (A91B2). The library connects that device with ECDH on the plain outer, as its capability byte (00) says, but its 0803 (a1 02 · a3 44 · a5 00) also offers AES, and on the encrypted outer it accepts it:

• 4005 states AES (a5 02); 4805 00 approves it.
• 4022 (clock), CBC-sealed under the static key and IV, gets 4822 00 a1 10 <16-byte key>.
• The session then runs GCM under that key with the static nonce.

test_legacy_aes_path_on_the_encrypted_outer checks the real 4022/4822 pair from that run, so the tests are no longer synthetic-only.

Still untested on hardware: the plain-outer leg after 4822 (CBC under the 4822 key, serial as IV), which is the #63 case. #63 F3800 owners: the request above still stands.

---

And the best part: the A91B2 test I mentioned above was done via #81 , so it not only demonstrated that the CLI works, but that I was able to try alternate methods of connecting that are not the library standard.