chore: rename quicproquo → quicprochat in docs, Docker, CI, and packaging

Rename all project references from quicproquo/qpq to quicprochat/qpc
across documentation, Docker configuration, CI workflows, packaging
scripts, operational configs, and build tooling.

- Docker: crate paths, binary names, user/group, data dirs, env vars
- CI: workflow crate references, binary names, artifact names
- Docs: all markdown files under docs/, SDK READMEs, book.toml
- Packaging: OpenWrt Makefile, init script, UCI config (file renames)
- Scripts: justfile, dev-shell, screenshot, cross-compile, ai_team
- Operations: Prometheus config, alert rules, Grafana dashboard
- Config: .env.example (QPQ_* → QPC_*), CODEOWNERS paths
- Top-level: README, CONTRIBUTING, ROADMAP, CLAUDE.md

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

@@ -1,15 +1,15 @@
 # Post-Quantum Readiness
 
-quicproquo includes a fully implemented and tested hybrid key encapsulation
+quicprochat 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/quicproquo-core/src/hybrid_kem.rs`
+**Source:** `crates/quicprochat-core/src/hybrid_kem.rs`
 
 ## Current State
 
-The hybrid KEM is **fully implemented and tested** in `quicproquo-core`. The
+The hybrid KEM is **fully implemented and tested** in `quicprochat-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. quicproquo uses ML-KEM-768, the
+post-quantum KEM, published as FIPS 203. quicprochat 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="quicproquo-hybrid-v1", L=32)
-nonce = HKDF-SHA256(salt=[], ikm, info="quicproquo-hybrid-nonce-v1", L=12)
+key  = HKDF-SHA256(salt=[], ikm, info="quicprochat-hybrid-v1", L=32)
+nonce = HKDF-SHA256(salt=[], ikm, info="quicprochat-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 quicproquo's post-quantum protection:
+There is an important asymmetry in quicprochat'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, quicproquo
+support it in a stable release. When `rustls` adds ML-KEM support, quicprochat
 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 quicproquo's case:
+In quicprochat'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