[dgarske]

The v1.85 ECC DHKEM path behind TPM2_Encapsulate / TPM2_Decapsulate (RFC 9180) calls wc_HKDF_Extract and wc_HKDF_Expand, but it was compiled whenever ML-KEM and HAVE_ECC were enabled. A user_settings.h build with ML-KEM and ECC but without HAVE_HKDF hit an implicit declaration and then an undefined reference at link. configure builds did not see it because wolfSSL enables HKDF by default.

Fix

• wolftpm/fwtpm/fwtpm.h - new FWTPM_HAVE_DHKEM, set when both HAVE_ECC and HAVE_HKDF are defined.
• src/fwtpm/fwtpm_crypto.c - the DHKEM helpers and FwEncapsulateEcdhDhkem / FwDecapsulateEcdhDhkem build under FWTPM_HAVE_DHKEM instead of HAVE_ECC.
• src/fwtpm/fwtpm_command.c - Encapsulate and Decapsulate dispatch an ECC key to DHKEM only under FWTPM_HAVE_DHKEM; otherwise the key is rejected with TPM_RC_KEY.
• tests/fwtpm_unit_tests.c - the DHKEM roundtrip tests are guarded on FWTPM_HAVE_DHKEM plus the ML-KEM encap/decap commands they drive.

ML-KEM itself is unaffected; only ECC KEM keys depend on HKDF.

Testing

• The STM32H5 fwTPM port (wolftpm-examples) built with ML-DSA + ML-KEM and without HAVE_HKDF now builds cleanly.
• configure sweep across default, swtpm, fwtpm, fwtpm v1.85, no-wrapper, no-examples, st33, advio, swtpm=uart and PQC client builds.
• fwtpm_unit.test DHKEM roundtrips pass (P-256, P-384, P-521).