Accept binary PSK identities when the installed transport supports them

[KRZ303]

Why this is needed

I recovered my oven's OwnerPSK, but its raw owner UUID contains NUL. LocalThings rejects that identity even when the transport can preserve it.

The transport fix adds an optional Mbed TLS backend. This PR lets LocalThings use it.

What changed

• Ask PskAuth.validate_identity() whether the transport supports the binary identity.
• Keep rejecting the all-zero UUID.
• Keep the existing error when the transport rejects the identity or lacks the native backend.
• Update the English and Polish messages.
• Update the credential/config-flow tests and add my Android recovery notes to docs/credential-acquisition.md.

The imported identity stays unchanged. Setup still requires successful authentication and the expected device ID from /oic/d. This doesn't add credential extraction or ownership transfer.

My result

My oven reports board prefix LCD_R18_SCO_QMD_EU_22K and profile DA-KS-OVEN-0105X. I haven't checked its retail model number yet.

I recovered its existing 16-byte PSK from an account-specific SmartThings .datenc store on rooted Android 17. I've published the scripts and procedure here.

With both patches and the native backend installed, I authenticated and read the expected /oic/d identity from macOS and my HA Linux runtime. I then imported the PSK and added the oven in HA. My certificate-based washer still loads too.

My oven currently exposes only a connection-mode sensor reporting poll, with no active observations. Authentication and setup work. Full oven entity coverage and heating controls aren't established.

Tests and dependency

All 2,633 integration tests passed against the patched transport. Fresh runs before publication passed all 2,633 against both the patched and released transports. Ruff format, Ruff lint, and ty passed too.

On my HA instance, deployed-file hashes and ha core check passed before I restarted HA.

The manifest still accepts smartthings-local>=0.1.21. That release safely rejects NUL identities. This PR alone won't enable them: you also need the transport patch and a compatible native build.

A transport release and native packaging are still needed for a normal install to support this. I've tested one oven, not other models or long-term stability.

Related: #435. This uses the existing PSK import flow.

[mbillow]

Thanks for the careful write-up. The code itself is fine: validate_identity exists in smartthings-local 0.1.21, so a normal install still rejects the identity as before. I'd like to hold the merge until it can do something for users, though:

1. Wait for the transport release. This only helps once SmartThings-Local Incomplete capability coverage for Samsung Aircondition #115 and a native Mbed TLS build are released. Let's merge it together with a manifest.json / requirements-dev.txt bump to that version rather than before.
2. The new error text. It tells users to install a "Mbed TLS backend" they can't get yet. Until there's a package to point them at, please keep the old wording, or say that support for these identities is coming.
3. Translations. Only en and pl are updated; the other seven languages still say "generate another one". Please update them too, or leave the key unchanged until the release.
4. Docs. The rooted-Android extraction walkthrough fits better in your own repository. A short paragraph in docs/credential-acquisition.md linking to it would be plenty.

---

Generated by Claude Code

[KRZ303]

@mbillow I pushed a92abff with the wording and docs changes:

• All nine translations now describe the installed transport's limitation and tell users to keep the recovered identity unchanged. They no longer recommend installing Mbed TLS or generating another identity.
• The Android walkthrough is replaced by a short paragraph linking to my recovery repository.
• The validation docstring is transport-neutral. The capability check and authentication behavior are unchanged.

One update on the dependency: QuiteYellow closed SmartThings-Local #115 in favor of the pure-Python engine in #117. #117 is still a draft and does not yet wire the engine into normal library sessions.

I agree that this PR should wait for a release providing that support. The manifest.json and requirements-dev.txt bump remains deferred until then.

On Python 3.14, all 2,633 integration tests passed against published smartthings-local==0.1.21. Ruff format/lint, ty, and whitespace checks also passed.