Feature/dlklap transport - #1729

Summary

Adds first-class support for the TP-Link DL100 smart lock via a new
DlklapTransport and a Lock SmartModule. Closes #1693.

The DL100 speaks DLKLAP, a proprietary KLAP variant that runs over plain
HTTP :80 and requires a cloud-assisted handshake0 step to mint a
per-session controlKey before the usual KLAP handshake1/handshake2 and
AES-128-CBC session encryption. This transport implements that full pipeline
and slots into the existing Transport / Protocol / Device layering.

What is DLKLAP?

Standard KLAP handshakes are fully local. DLKLAP inserts two cloud round-trips:

1. Cloud login (wap.tplinkcloud.com) → account token + accountId.
2. handshake0 to the lock over HTTP → a 236-char base64 secret (this
   also wakes the lock's radio).
3. control-key exchange (*.tplinknbu.com) binds that secret to a
   per-session controlKey.
4. handshake1 / handshake2 then proceed like KLAP, deriving the AES session
   keys (lsk/ldk/iv) used for /app/request.

Full protocol write-up is in #1693.

Changes

• kasa/transports/dlklaptransport.py — DlklapTransport(BaseTransport)
  • _DlklapSession. Implements
    handshake0 → control-key → handshake1 → handshake2 → session-key derivation,
    session caching, and single-retry re-handshake on failure. Handshakes are
    serialized (asyncio.Lock) since a second handshake0 invalidates the first
    control key (device error 15033).
• kasa/smart/modules/lock.py — Lock(SmartModule):
  is_locked, lock(), unlock(), battery, battery_low.
• Device/discovery wiring — DeviceEncryptionType.Dlklap = "DLKLAP",
  DeviceFamily.SmartTapoLock = "SMART.TAPOLOCK", DeviceType.Lock, the
  SMART.DLKLAP → (SmartProtocol, DlklapTransport) mapping in
  device_factory.py, and the SMART.TAPOLOCK → DeviceType.Lock mapping in
  smartdevice.py.
• Tests — tests/smart/modules/test_lock.py (mocked, no live device) plus a
  redacted DL100 fixture folded into the parametrized SMART suite.
• pyproject.toml — adds httpx to dependencies.

Behavior notes for reviewers

• httpx used directly (not HttpClient) in the transport. This is
  deliberate: the 33-byte binary handshake0 body must be sent verbatim, and
  wrapping middleware re-encodes the text/plain payload and breaks the
  handshake. Happy to revisit if there's a preferred integration point.
• verify=False is scoped to a single call. The control-key host presents
  TP-Link's private CA (not a public root), so TLS verification is disabled for
  that one request only (# noqa: S501 with a comment). The cloud login
  call, which carries the account password, stays fully verified.
• Battery lives on the Lock module because the DL100 lacks the
  battery_detect component, so the generic BatterySensor never loads.
• Lock-status polarity is counterintuitive and verified: 0 = LOCKED
  (bolt extended), 1 = UNLOCKED. Confirmed against decompiled
  EnumDoorLockStatus and the live device — not inverted.

Testing

• Unit tests: pytest tests/smart/modules/test_lock.py — all pass
  (module presence, is_locked polarity, lock()/unlock() payload with
  owner-forbidden fields excluded, battery).
• Full suite: pytest tests/ — 22,856 passed, 883 skipped, 0 failures,
  including the test_devtools.py fixture round-trip check.
• Type/lint: mypy clean on the new files; ruff/ruff format clean.
• Live device: verified end-to-end against a real DL100 (fw 1.0.17) via
  device_factory.connect() → update() — is_locked=True (lock_status 0),
  battery_level=81, battery_low=False.

Known limitations / follow-ups

• _ensure_device_id can't disambiguate multiple locks on one account (the
  cloud device list has no LAN IP), so it picks the sole SMART.TAPOLOCK.
  A future config override could address multi-lock setups.
• The DL100 advertises a speaker component it doesn't implement
  (getVolume → UNKNOWN_METHOD_ERROR); handled gracefully (module marked
  unavailable). Cosmetic device quirk, not a bug.
• This transport requires cloud round-trips (wap.tplinkcloud.com, tplinknbu.com) mid-handshake. The DL100 mints its controlKey via the cloud (there's no local-only path). The correct local-first implementation necessarily includes these minimal cloud round-trips.