System crypto backends don't support HKDF/HMAC with SHA-3

[michelle-clayton-work]

Under a system crypto backend, HKDF and HMAC with SHA-3 are not yet supported on
every platform. The pure-Go path and OpenSSL (Linux) compute them natively;
CryptoKit (macOS) and CNG (Windows) currently fall back to the Go implementation,
for different reasons. This issue tracks closing those gaps.

Until they're closed, the SHA-3 regression tests added in #2360 / #2361 skip on
any backend that reports SHA-3 as unsupported, so results stay correct everywhere
via the Go fallback.

macOS / CryptoKit — binding gap (fillable), targeted for Go 1.27

CryptoKit implements both SHA-3 HMAC and SHA-3 HKDF on macOS 26+ — verified by
compiling and running HMAC<SHA3_256/384/512> and HKDF<SHA3_256/384/512>
against CryptoKit on macOS 26 (SHA3_* conforms to the HashFunction protocol
that both generics require).

The gap is in the go-crypto-darwin bindings: go_initHMAC (and
go_extractHKDF / go_expandHKDF) only switch over MD5/SHA-1/SHA-256/SHA-384/
SHA-512 and report anything else as unsupported. Previously HMAC aborted the
process on SHA-3; microsoft/go-crypto-darwin#216 changed it to return nil so the
standard library falls back to Go.

To close it:

• Add SHA3_256/384/512 cases to the HMAC and HKDF Swift bindings, gated on
  #available(macOS 26.0, *), mirroring the existing SHA-3 hashing bindings.
• Extend the xcrypto NewHMAC allowlist and HKDF path to accept SHA-3 when
  SupportsHash reports it (macOS 26+).
• Result: SHA-3 HMAC/HKDF run natively under CryptoKit on macOS 26+, and continue
  to fall back to Go on older macOS.

Windows / CNG — version-gated, not a permanent gap

On Windows builds where CNG does not expose SHA-3 hashing, sha3.New256 never
becomes backend-backed, so CNG's HKDF rejects it with cng: unsupported hash function. On Windows 24H2 / Server 2025+ (where CNG exposes SHA-3) this path can
behave differently.

---

• Fix HKDF and HMAC with SHA-3 under system crypto backends #2360 (comment)