ML-KEM heads up on hppa

I have not had time to fully run this down yet, and may never.  But
offered here as it's the first problem of this kind I've encountered
as the PQC era looms before us.

I have a small application which uses a TLS-PSK protected connection
between a host (Linux, on amd64, with OpenSSL 3.5) and guest (NetBSD/hppa, in
QEMU, with NetBSD 11 and the in-tree OpenSSL).

Allowed to negotiate TLS 1.3 with the default ML-KEM + X25519 key exchange
these two and *only* these two peers get record decryption failures (a
peculiarity of ML-KEM; you get the wrong traffic secret out instead of
a clean failure).  Switching to just X25519 fixes things (note there is
no loss of quantum resistance -- half the key bits come from the PSK --
making ML-KEM rather pointless for PSK mode anyway).

This host manages QEMU guests running the exact same version of NetBSD
on 14 other emulated architectures.  Only hppa blows up like this.  I
suppose some day someone will figure out why.

-- 
Thor Lancelot Simon	                                     [email protected]
  "Indeed, someone who is a citizen in a democracy is often not one in
   an oligarchy."
					- Aristotle, Politics III.1