PKCS#11 hardcodes key_block=0

[anpa8480]

Describe the bug
PKCS#11 hardcodes key_block=0
File: lib/pkcs11/pkcs11_encrypt.c, line ~206

To Reproduce
Steps to reproduce the behavior:

1. Provision slot 5 block 1 with all-zero key (workaround for bug,).
2. Verify native API works with block 1:

atcab_aes_encrypt_ext(dev, 5, 1, pt_zeros, ct);
// ct == 66e94bd4ef8a2c3b884cfa59ca342b2e ✓

3. Use PKCS#11 C_Encrypt(CKM_AES_ECB) on the same slot:

C_EncryptInit(sess, &ecb_mech, slot5_key_handle);
C_Encrypt(sess, pt_zeros, 16, ct, &clen);
// ct != 66e94bd4... — PKCS#11 used block 0 (corrupted), not block 1

4. Inspect source — pkcs11_encrypt.c passes 0 as key_block unconditionally:

atcab_aes_encrypt_ext(pSession->slot->device_ctx, pKey->slot, 0, ...);
//                                                            ^ hardcoded

Expected behavior
PKCS#11 should use the correct key_block (configurable or at least block 0 should work with write_enc).
Actual: Always uses block 0, with no way to select an alternate block. Combined with bug, AES via PKCS#11 is broken for any encrypted-write slot.
Proof of correct hardware: Slot 9 (WrCfg=0, clear-text write) passes all NIST vectors through both native API and PKCS#11, confirming the silicon AES engine is correct — the bug is purely in the software library.

Additional context
ATECC608B TrustFLEX, RPi4, USB HID
cryptoauthlib version (v3.8.0)