load_ak/create_ak fail with tpm2-tss >= 4.2.0 due to unsalted encrypted sessions

Problem

load_ak() and create_ak() in src/abstraction/ak.rs create unsalted
policy sessions with encrypt+decrypt attributes:

context.start_auth_session(None, None, None, SessionType::Policy, ...)

tpm2-tss 4.2.0 introduced a regression (tpm2-software/tpm2-tss@9f1f612) that
broke ESAPI parameter encryption for unsalted sessions. When encrypt/decrypt
session attributes are set on an unsalted session, the ESAPI layer produces
incorrect parameter encryption, causing TPM_RC_SIZE (0x000001d5) errors.

This affects Fedora 45 (which ships tpm2-tss 4.2.0) and any distribution or
environment running tpm2-tss >= 4.2.0.

Reproduction

Using the existing integration tests built against tpm2-tss 4.2.0 with swtpm:

test abstraction_tests::ak_tests::test_create_ak_ecc       ... FAILED
test abstraction_tests::ak_tests::test_create_and_use_ak   ... FAILED

Both fail with:

ErrorCode (0x000001d5)
TpmFormatOneResponseCode { error_number: Size, argument_number: Parameter(1) }

Proposed fix

Pass the parent EK handle as tpmKey to start_auth_session so sessions are
salted, in both load_ak() and create_ak():

context.start_auth_session(Some(parent.into()), None, None, SessionType::Policy, ...)

The parent handle is already available as a parameter in both functions.

While the immediate trigger is the tpm2-tss 4.2.0 regression, switching to
salted sessions is the right fix regardless:

• Security improvement: unsalted encrypted sessions derive the session
  encryption key from plaintext nonces only, providing no real confidentiality.
  Salted sessions establish a proper shared secret via the TPM key (RSA-encrypted
  salt for RSA EKs, ECDH key agreement for ECC EKs), giving meaningful protection
  of the encrypted parameters on the bus.

• Alignment with tpm2-tools: tpm2-tools already uses salted sessions for
  AK operations (e.g. tpm2_createak). This change brings rust-tss-esapi in
  line with that established practice.

• No compatibility impact: the session type is transport-level only and does
  not affect persisted AK blobs or any stored state.

Verification

With the fix applied, all 7 AK integration tests pass against tpm2-tss 4.2.0,
covering both RSA and ECC parent EKs:

test abstraction_tests::ak_tests::test_create_ak_rsa_rsa     ... ok  (RSA 2048 EK)
test abstraction_tests::ak_tests::test_create_ak_rsa_rsa_3072 ... ok (RSA 3072 EK)
test abstraction_tests::ak_tests::test_create_ak_rsa_ecc     ... ok  (RSA 2048 EK)
test abstraction_tests::ak_tests::test_create_ak_ecc         ... ok  (ECC P384 EK)
test abstraction_tests::ak_tests::test_create_ak_ecdaa       ... ok  (ECC P384 EK)
test abstraction_tests::ak_tests::test_create_custom_ak       ... ok (RSA 2048 EK)
test abstraction_tests::ak_tests::test_create_and_use_ak      ... ok (RSA 2048 EK)

I'll follow up with a PR containing the fix.

This issue was created with the help of AI (Claude Code by Anthropic).

Start in src/abstraction/ak.rs by inspecting the start_auth_session calls in load_ak() and create_ak(), then review the existing AK integration tests. Verify the session setup with the parent EK handle and run the AK tests against tpm2-tss 4.2.0 and swtpm; done means all seven listed RSA and ECC tests pass.