chore: rename project quicnprotochat -> quicproquo (binaries: qpq)

Rename the entire workspace:
- Crate packages: quicnprotochat-{core,proto,server,client,gui,p2p,mobile} -> quicproquo-*
- Binary names: quicnprotochat -> qpq, quicnprotochat-server -> qpq-server,
  quicnprotochat-gui -> qpq-gui
- Default files: *-state.bin -> qpq-state.bin, *-server.toml -> qpq-server.toml,
  *.db -> qpq.db
- Environment variable prefix: QUICNPROTOCHAT_* -> QPQ_*
- App identifier: chat.quicnproto.gui -> chat.quicproquo.gui
- Proto package: quicnprotochat.bench -> quicproquo.bench
- All documentation, Docker, CI, and script references updated

HKDF domain-separation strings and P2P ALPN remain unchanged for
backward compatibility with existing encrypted state and wire protocol.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/src/cryptography/post-quantum-readiness.md

@@ -1,15 +1,15 @@
 # Post-Quantum Readiness
 
-quicnprotochat includes a fully implemented and tested hybrid key encapsulation
+quicproquo includes a fully implemented and tested hybrid key encapsulation
 mechanism (KEM) combining X25519 (classical) with ML-KEM-768 (post-quantum).
 This page describes the current implementation, the integration plan, the
 security rationale, and the known gaps.
 
-**Source:** `crates/quicnprotochat-core/src/hybrid_kem.rs`
+**Source:** `crates/quicproquo-core/src/hybrid_kem.rs`
 
 ## Current State
 
-The hybrid KEM is **fully implemented and tested** in `quicnprotochat-core`. The
+The hybrid KEM is **fully implemented and tested** in `quicproquo-core`. The
 implementation provides:
 
 - `HybridKeypair::generate()` -- generate a combined X25519 + ML-KEM-768 keypair
@@ -35,7 +35,7 @@ The test suite in `hybrid_kem.rs` includes 10 tests covering:
 ## ML-KEM-768 (FIPS 203)
 
 ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) is the NIST-standardized
-post-quantum KEM, published as FIPS 203. quicnprotochat uses ML-KEM-768, the
+post-quantum KEM, published as FIPS 203. quicproquo uses ML-KEM-768, the
 middle parameter set:
 
 | Parameter Set | NIST Level | Security (PQ) | EK Size | CT Size | SS Size |
@@ -69,8 +69,8 @@ executed, and their shared secrets are combined through a KDF:
 
 ```text
 ikm  = X25519_shared_secret(32 bytes) || ML-KEM_shared_secret(32 bytes)
-key  = HKDF-SHA256(salt=[], ikm, info="quicnprotochat-hybrid-v1", L=32)
-nonce = HKDF-SHA256(salt=[], ikm, info="quicnprotochat-hybrid-nonce-v1", L=12)
+key  = HKDF-SHA256(salt=[], ikm, info="quicproquo-hybrid-v1", L=32)
+nonce = HKDF-SHA256(salt=[], ikm, info="quicproquo-hybrid-nonce-v1", L=12)
 ```
 
 The combined IKM (input key material) is wrapped in `Zeroizing<Vec<u8>>` and
@@ -165,7 +165,7 @@ hybrid KEM for HPKE init key exchange:
 
 ## The PQ Gap
 
-There is an important asymmetry in quicnprotochat's post-quantum protection:
+There is an important asymmetry in quicproquo's post-quantum protection:
 
 ```text
 Layer                  Classical Protection    Post-Quantum Protection
@@ -191,7 +191,7 @@ This is the **PQ gap**: content is safe, but metadata is not.
 
 Post-quantum TLS (via ML-KEM in the TLS 1.3 handshake) is being standardized by
 the IETF and is supported by some TLS libraries, but `rustls` does not yet
-support it in a stable release. When `rustls` adds ML-KEM support, quicnprotochat
+support it in a stable release. When `rustls` adds ML-KEM support, quicproquo
 will adopt it to close the PQ gap at the transport layer.
 
 ## Harvest-Now, Decrypt-Later Risk
@@ -202,7 +202,7 @@ The "harvest-now, decrypt-later" (HNDL) threat model assumes an adversary who:
 2. Waits for a sufficiently powerful quantum computer (years or decades).
 3. Decrypts the recorded traffic retroactively.
 
-In quicnprotochat's case:
+In quicproquo's case:
 
 - **Content is safe from M5 onward.** The hybrid KEM wrapping MLS content uses
   ML-KEM-768, which resists quantum attacks. Even if the recorded traffic is