Mlkem cryptocb sha3 hashtype not reset after final call

[night1rider]

Issue

wc_Sha3Update and wc_Sha3Final cache sha3->hashType on first use and pass it to wc_CryptoCb_Sha3Hash for dispatch. The state reset at the end of wc_Sha3Final (via InitSha3) only cleared the sponge bytes, leaving hashType latched. Any caller that legitimately reuses a single wc_Sha3 across SHA3 variants (mlkem reuses key->hash for SHA3-512 MLKEM_HASH_G in MakeKey, then SHA3-256 MLKEM_HASH_H in EncodePublicKey/DecodePrivateKey) would have the second op dispatched through the crypto callback as the first op's algorithm. That produces a wrong key->h, fails wc_MlKemKey_DecodePrivateKey with MLKEM_PUB_HASH_E, and in the SHA3-512 over a 32 byte buffer case overwrites adjacent fields.

The software path was unaffected because it keys off the p block count parameter every call. The callback path only stayed hidden because the devId != INVALID_DEVID guard usually kept it cold. -DWOLF_CRYPTO_CB_FIND removes that guard and makes it reliably trigger.

Fix

Clear sha3->hashType inside InitSha3 and wc_Sha3Final already calls InitSha3 for its end of op reset, so the the sha3 struct will reinit and subsequent Update/Final calls can determine the correct type from p.

Also fix -Wparentheses-equality error when WOLF_CRYPTO_CB_FIND is defined with clang

Test

New --enable-cryptocb --enable-keygen -DWOLF_CRYPTO_CB_FIND entry in .github/workflows/os-check.yml reproduces the failure on master and passes with this fix.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #10211

Scan targets checked: wolfcrypt-api_misuse, wolfcrypt-bugs, wolfcrypt-compliance, wolfcrypt-concurrency, wolfcrypt-consttime, wolfcrypt-defaults, wolfcrypt-mutation, wolfcrypt-portability, wolfcrypt-proptest, wolfcrypt-src, wolfcrypt-zeroize

No new issues found in the changed files. ✅