crypto: make ML-KEM-768 genuinely FIPS 203-conformant (validated vs OpenSSL)

The in-tree ML-KEM-768 was round-3 CRYSTALS-Kyber mislabelled "FIPS 203" and
was NOT interoperable with a compliant ML-KEM. Discovered and fixed by
validating against OpenSSL 3.5's FIPS 203 ML-KEM-768 as an oracle.

Three deviations, all fixed in src/zupt_mlkem.c:
1. Matrix  transpose convention. FIPS 203 K-PKE.KeyGen samples
   Â[i][j] = SampleNTT(XOF(ρ, j, i)) and K-PKE.Encrypt uses (ρ, i, j); the
   code had both index orders swapped. It was self-consistent (encaps/decaps
   round-tripped) but transposed vs the standard — which is exactly why a
   self-consistency-only round-trip test never caught it. With the same seed,
   keygen now produces a byte-identical ek to OpenSSL.
2. Shared-secret KDF. FIPS 203 returns K = G(m‖H(ek))[0:32] directly; removed
   the round-3 final K = KDF(K̄‖H(c)) step (encaps + decaps success key).
3. Implicit rejection. Now K̄ = J(z‖c) = SHAKE256(z ‖ full-ciphertext) instead
   of the round-3 KDF(z‖H(c)).

Validation (tests/test_mlkem_fips203.sh + mlkem_fips203_harness.c, wired into
make check): against OpenSSL 3.5 ML-KEM-768 —
  - deterministic keygen (same d‖z seed) -> byte-identical ek
  - our encaps -> OpenSSL decap: shared secret matches
  - OpenSSL encap -> our decaps: shared secret matches
The harness feeds a fixed random stream (MLKEM_RAND) so the FIPS 203 seed is
reproducible; the test skips gracefully without an ML-KEM-capable openssl.

BREAKING: --pq / --pq-only keys and archives from <= 4.2.1 no longer decrypt
(the KEM math changed). Regenerate keys and re-encrypt. Password mode and plain
compression are unaffected; wire format stays v1.6. make check 16/16.

CHANGELOG.md

@@ -1,6 +1,35 @@
 # VaptVupt Changelog
 
 
+## [5.0.0] — unreleased — genuine FIPS 203 ML-KEM-768 (breaking PQ change)
+
+### Security / correctness — ML-KEM-768 is now FIPS 203-conformant
+
+- The in-tree ML-KEM-768 was **round-3 CRYSTALS-Kyber, not final FIPS 203**, and
+  therefore not interoperable with a compliant ML-KEM despite the "FIPS 203"
+  label. Three deviations were found and fixed:
+  1. **Matrix  transpose convention** — K-PKE.KeyGen must use `SampleNTT(ρ‖j‖i)`
+     and K-PKE.Encrypt `SampleNTT(ρ‖i‖j)`; the implementation had both swapped.
+     Self-consistent (round-trips passed) but non-standard, which is exactly why
+     a self-consistency-only test never caught it.
+  2. **Encaps/decaps KDF** — FIPS 203 outputs `K` from `G(m‖H(ek))` directly; the
+     round-3 final `K = KDF(K̄‖H(c))` step was removed.
+  3. **Implicit rejection** — now `K̄ = J(z‖c)` (SHAKE256 over the full
+     ciphertext) instead of `KDF(z‖H(c))`.
+- **Validated for genuine conformance against OpenSSL 3.5's FIPS 203 ML-KEM-768**
+  (`tests/test_mlkem_fips203.sh`, wired into `make check`): deterministic keygen
+  produces byte-identical `ek`, and the shared secret matches in **both**
+  cross-decapsulation directions (our encaps ↔ OpenSSL decaps, and vice-versa).
+  This replaces the previous self-consistency-only round-trip test.
+
+### BREAKING
+
+- **`--pq` and `--pq-only` keys and archives created by ≤ 4.2.1 are not
+  readable by this release** (the KEM math changed). Regenerate keys
+  (`keygen`/`keygen --pq-only`) and re-encrypt affected archives. Password mode
+  (`-p`) and plain compression are unaffected. Wire format stays v1.6.
+
+
 ## [4.2.1] — 2026-07-10 — `info` correctly reports the post-quantum mode
 
 ### Fixed