v5.0.0: version bump, audit fixes, documentation overhaul

Version bumped to 5.0.0 across include/zupt.h, all packaging recipes, man
page, and docs.

Audit fixes (pre-5.0.0 review):
- src/zupt_format.c: overflow-safe bound in the solid-mode `test` path
  (off+sz could wrap and drive an OOB read in zupt_xxh64 on a crafted archive;
  the extract path was already hardened, the test path was not).
- gui: run_async now marshals the completion callback onto the GUI thread with
  QueuedConnection (a bare functor connected DirectConnection and touched
  widgets off the worker thread); Extract auto-detect note survives the log
  clear via a new `info` param.
- .github/workflows/ci.yml: trigger on `master` (was main/develop, so CI never
  ran); `make dist` tarball is vaptvupt-*.tar.gz not zupt-*; the ASAN PQ
  round-trip uses native --pq (was --pq-sdk, which fails on the source-only
  build and blocked the release job).

Documentation:
- New AUDIT.md (methodology, FIPS 203 conformance validation, findings, repro).
- CHANGELOG 5.0.0 entry covers the FIPS 203 conformance fix + BREAKING note and
  the GUI/CLI/security/packaging work.
- README "What's new in 5.0.0", download tables (incl. Windows/macOS/BSD +
  portable GUI), version-history row.
- SECURITY.md + THREAT_MODEL.md: ML-KEM-768 documented as FIPS 203, validated
  byte-for-byte against OpenSSL 3.5.
- Accuracy fixes: man page (--kdf default is PBKDF2 on source-only; codec
  2.60.4), rpm %description, debian control/copyright, homebrew header
  (no vendored library on source-only builds).

make check 16/16 (FIPS 203 conformance 3/3, all distro-safe checks).

SECURITY.md

@@ -1,4 +1,4 @@
-# Security Policy — VaptVupt 4.2.1
+# Security Policy — VaptVupt 5.0.0
 
 ## Reporting Vulnerabilities
 
@@ -61,7 +61,7 @@ build and are not defaults.
 | Authentication | HMAC-SHA256 | RFC 2104 | 256-bit | 128-bit post-quantum (Grover) |
 | Password KDF (default) | PBKDF2-SHA256 | RFC 8018 | 600K iterations | Password-dependent |
 | Password KDF (WITH_SDK=1 option) | Argon2id | RFC 9106 | OWASP minimums | Password-dependent, memory-hard |
-| Post-quantum KEM | ML-KEM-768 | FIPS 203 | 1184B pk / 2400B sk | NIST Level 3 |
+| Post-quantum KEM | ML-KEM-768 | FIPS 203 (validated vs OpenSSL 3.5) | 1184B ek / 2400B dk | NIST Level 3 |
 | Classical KEM | X25519 | RFC 7748 | 32B scalar | ~128-bit classical |
 | Hybrid KDF (`--pq`) | SHA3-512 | FIPS 202 | 512-bit output | Secure if either KEM holds |
 | PQ-only KDF (`--pq-only`) | SHA3-512 | FIPS 202 | 512-bit output | Secure if ML-KEM-768 holds (no classical fallback) |
@@ -112,6 +112,14 @@ decryption. This prevents:
 
 ### Hybrid Post-Quantum KEM (`--pq`)
 
+> **FIPS 203 conformance (v5.0.0).** The ML-KEM-768 implementation is validated
+> byte-for-byte against OpenSSL 3.5's FIPS 203 ML-KEM-768: deterministic keygen
+> produces an identical `ek`, and the shared secret agrees in both
+> cross-decapsulation directions (our encaps ↔ OpenSSL decaps, and vice-versa).
+> This is checked on every `make check` by `tests/test_mlkem_fips203.sh`.
+> Releases ≤ 4.2.1 used round-3 CRYSTALS-Kyber (secure, but not interoperable);
+> 5.0.0's `--pq`/`--pq-only` archives are therefore not backward-compatible.
+
 ```
 Encapsulation:
   ML-KEM-768.Encaps(pk)  → ml_ct[1088], ml_ss[32]