… HardwareKey

HardwareKey.rsa_key_bits/committed_alg and its
load_ds_params()/sign()/decrypt() methods were a "DS purpose only"
bolt-on that didn't belong on a type meant to be a generic key handle
shared with hmac.new().

HardwareKey goes back to a pure generic handle: key_slot, purpose,
exportable, name/__repr__, __bool__, and nothing else. The only
DS-flavored thing left on it is Purpose.HMAC_DOWN_DIGITAL_SIGNATURE
itself, which is fine since it's the type definition tannewt said not
to touch. This mirrors the same correction this codebase already made
once: commit 965a59e removed HardwareKey.hmac_sha256()/
verify_hmac_sha256() in favor of hmac.new() type-checking a generic
HardwareKey and doing its own PSA wiring.

New type hardwarekey.DigitalSignatureKey, obtained via
hardwarekey.load_digital_signature_key(key, ds_params), mirrors
cryptography.hazmat.primitives.serialization.load_pem_private_key():
a blob of key material in, a ready-to-use key object out. The purpose
check now happens once at load time instead of on every sign()/
decrypt() call; after that, the type's existence is itself the proof
the key is DS-capable. rsa_key_bits is renamed to key_size to match
cryptography.hazmat...RSAPrivateKey.key_size exactly. sign()/decrypt()
move here verbatim from the old HardwareKey methods, unchanged in
behavior.

    key = board.EFUSE_KEY4
    ds_key = hardwarekey.load_digital_signature_key(
        key, ds_params=open("/ds_params.bin", "rb").read()
    )
    signature = ds_key.sign(
        data=b"...", padding=crypto_primitives.PKCS1v15, algorithm=crypto_primitives.SHA256
    )
    plaintext = ds_key.decrypt(ciphertext=ciphertext, padding=crypto_primitives.PKCS1v15)
    ctx.load_cert_chain(certfile="/client.pem", keyfile=ds_key)

Generation-counter guard: load_digital_signature_key() returns a new
object each call, but the port's per-slot ds_params cache is still a
single, physical-slot-indexed array. Without a guard, an older,
not-yet-used DigitalSignatureKey held across a second load for the
same slot would silently import the new load's key material on first
use instead of failing loudly. Fixed with a generation counter on the
port's cache, snapshotted at construction and checked before the first
PSA import: a stale key now raises ValueError instead of silently
signing/decrypting with the wrong key material.

load_digital_signature_key()'s key argument is validated with the
existing mp_arg_validate_type() helper rather than a hand-rolled
raise, reusing an already-translated string instead of adding a new
one.

ssl.SSLContext.load_cert_chain()'s keyfile type check and docstring
move to hardwarekey.DigitalSignatureKey; the manual purpose check is
removed since the type itself is now the proof.

Hardware-reverified end to end on an ESP32-S3-DevKitC-1-N8R8
(BLOCK_KEY4): sign() output independently verified with openssl dgst
-verify; decrypt() (both PKCS1v15 and OAEP paddings) round-trips
against independently-generated openssl pkeyutl ciphertext; the
one-algorithm-per-lifetime commitment guard and the new
generation-counter guard both raise ValueError exactly as designed;
mutual TLS via ssl.load_cert_chain(keyfile=ds_key) completes an
on-device SoftAP loopback handshake with a DS-key client certificate
and correctly times out with no certificate; hmac.new()'s existing
eFuse HMAC path (BLOCK_KEY5) shows no regression.