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/forward-secrecy.md

@@ -6,7 +6,7 @@ compromised, past session keys cannot be recovered.** In other words, an
 attacker who obtains today's long-term key cannot use it to decrypt messages
 recorded yesterday.
 
-quicnprotochat provides forward secrecy at two independent layers: the transport
+quicproquo provides forward secrecy at two independent layers: the transport
 layer and the application layer. Even if one layer's FS mechanism is defeated,
 the other continues to protect message confidentiality.
 
@@ -28,7 +28,7 @@ In each TLS 1.3 handshake:
 
 Because the ephemeral keys exist only for the duration of the handshake,
 compromising the server's long-term TLS certificate key (currently self-signed
-in quicnprotochat) does not reveal past session keys.
+in quicproquo) does not reveal past session keys.
 
 ## Application Layer Forward Secrecy
 
@@ -54,7 +54,7 @@ This deletion is the mechanism that provides forward secrecy: once old epoch
 keys are erased, messages encrypted under those keys cannot be decrypted, even
 if the current group state is compromised.
 
-In quicnprotochat, epoch advancement occurs when:
+In quicproquo, epoch advancement occurs when:
 
 - `add_member()` is called, which creates a Commit and calls
   `merge_pending_commit()`.
@@ -91,7 +91,7 @@ HPKE init keys.
 
 ## Layered Forward Secrecy
 
-A distinctive property of quicnprotochat's design is that forward secrecy
+A distinctive property of quicproquo's design is that forward secrecy
 operates at two independent layers:
 
 ```text
@@ -135,7 +135,7 @@ unless they also break the transport encryption.
 Signal's Double Ratchet protocol also provides forward secrecy, but the
 mechanisms differ:
 
-| Property | Signal Double Ratchet | MLS (quicnprotochat) |
+| Property | Signal Double Ratchet | MLS (quicproquo) |
 |----------|----------------------|---------------------|
 | Scope | Pairwise (1:1 sessions) | Group (n-party) |
 | Ratchet granularity | Per message (symmetric ratchet) + per DH round (DH ratchet) | Per epoch (Commit) |

docs/src/cryptography/identity-keys.md

@@ -1,11 +1,11 @@
 # Ed25519 Identity Keys
 
 The Ed25519 identity keypair is the long-term cryptographic identity of a
-quicnprotochat client. It is generated once, persisted across sessions, and used
+quicproquo client. It is generated once, persisted across sessions, and used
 for MLS credential signing, Authentication Service registration, and delivery
 queue addressing.
 
-**Source:** `crates/quicnprotochat-core/src/identity.rs`
+**Source:** `crates/quicproquo-core/src/identity.rs`
 
 ## Structure
 
@@ -37,7 +37,7 @@ A fresh identity keypair is generated from the OS CSPRNG (`OsRng`) via
 `ed25519-dalek`:
 
 ```rust
-use quicnprotochat_core::identity::IdentityKeypair;
+use quicproquo_core::identity::IdentityKeypair;
 
 let identity = IdentityKeypair::generate();
 // The signing key seed is generated from OsRng (getrandom on Linux).

docs/src/cryptography/key-lifecycle.md

@@ -1,6 +1,6 @@
 # Key Lifecycle and Zeroization
 
-quicnprotochat uses multiple key types with different lifetimes, creation
+quicproquo uses multiple key types with different lifetimes, creation
 patterns, and destruction guarantees. This page provides a comprehensive
 lifecycle diagram for every key type in the system, from generation through
 zeroization.
@@ -25,7 +25,7 @@ Hybrid KEM Keys       Per peer (future)   Public portion       X25519+ML-KEM-768
 
 ## Ed25519 Identity Key
 
-**Source:** `crates/quicnprotochat-core/src/identity.rs`
+**Source:** `crates/quicproquo-core/src/identity.rs`
 
 The Ed25519 identity key is the most long-lived secret in the system. It
 represents the client's cryptographic identity across all sessions and groups.
@@ -92,8 +92,8 @@ zeroization.
 
 ## HPKE Init Keys
 
-**Source:** `crates/quicnprotochat-core/src/keystore.rs` and
-`crates/quicnprotochat-core/src/group.rs`
+**Source:** `crates/quicproquo-core/src/keystore.rs` and
+`crates/quicproquo-core/src/group.rs`
 
 HPKE init keys are generated by the openmls backend as part of MLS KeyPackage
 creation. They are single-use: each init key is consumed exactly once when
@@ -167,7 +167,7 @@ processing a Welcome message.
 **Managed by:** `openmls` (internal to the `MlsGroup` state machine)
 
 MLS epoch keys are derived internally by the openmls ratchet tree. They are not
-directly accessible in quicnprotochat code but are critical to understanding the
+directly accessible in quicproquo code but are critical to understanding the
 system's security properties.
 
 ### Lifecycle
@@ -216,12 +216,12 @@ system's security properties.
 - **Deletion:** Old epoch keys are deleted after the Commit is processed. This
   deletion is what provides [forward secrecy](forward-secrecy.md) at the MLS
   layer.
-- **No direct access:** quicnprotochat code interacts with epoch keys only
+- **No direct access:** quicproquo code interacts with epoch keys only
   indirectly through `send_message()` and `receive_message()`.
 
 ## Hybrid KEM Keys (Future -- M5+)
 
-**Source:** `crates/quicnprotochat-core/src/hybrid_kem.rs`
+**Source:** `crates/quicproquo-core/src/hybrid_kem.rs`
 
 The hybrid KEM keypair combines X25519 (classical) with ML-KEM-768
 (post-quantum) for content encryption that resists both classical and quantum

docs/src/cryptography/overview.md

@@ -1,6 +1,6 @@
 # Cryptography Overview
 
-quicnprotochat layers multiple cryptographic protocols to provide confidentiality,
+quicproquo layers multiple cryptographic protocols to provide confidentiality,
 integrity, authentication, forward secrecy, and post-compromise security. This
 page catalogues every algorithm in the system, the crate that supplies it, and
 the security margin it provides.

docs/src/cryptography/post-compromise-security.md

@@ -13,7 +13,7 @@ PCS is the complement of [forward secrecy](forward-secrecy.md):
 - **Post-compromise security** protects the **future** from a past compromise.
 
 MLS (RFC 9420) is specifically designed to provide both properties simultaneously
-for group messaging. This is a key differentiator of quicnprotochat's design.
+for group messaging. This is a key differentiator of quicproquo's design.
 
 ## How MLS Provides PCS
 
@@ -64,7 +64,7 @@ This means:
 For a group of 1,000 members, the path length is approximately 10 nodes --
 making PCS practical even for large groups.
 
-## Epoch Advancement in quicnprotochat
+## Epoch Advancement in quicproquo
 
 In the current implementation, epoch advancement occurs through the `GroupMember`
 methods in `group.rs`:
@@ -145,7 +145,7 @@ deleted), and future epochs are protected by PCS (new key material generated).
 
 Signal's group messaging uses **Sender Keys**, a fundamentally different
 mechanism from MLS's ratchet tree. The comparison is instructive because it
-highlights why MLS was chosen for quicnprotochat:
+highlights why MLS was chosen for quicproquo:
 
 ### Signal Sender Keys
 
@@ -168,7 +168,7 @@ security. If an attacker compromises a member's Sender Key:
   membership changes.
 - There is no automatic healing mechanism analogous to MLS's ratchet tree.
 
-### MLS Ratchet Tree (quicnprotochat)
+### MLS Ratchet Tree (quicproquo)
 
 In contrast, MLS's ratchet tree provides PCS because:
 
@@ -218,7 +218,7 @@ periodic Updates (planned) will bound the healing window.
 
 ### Server compromise does not prevent PCS
 
-The quicnprotochat server is MLS-unaware -- it stores and forwards encrypted
+The quicproquo server is MLS-unaware -- it stores and forwards encrypted
 MLS messages without access to the group state. A compromised server cannot:
 
 - Prevent PCS by blocking Commits (it could perform denial-of-service, but

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

docs/src/cryptography/threat-model.md

@@ -1,6 +1,6 @@
 # Threat Model
 
-This page defines the attacker models quicnprotochat is designed to resist,
+This page defines the attacker models quicproquo is designed to resist,
 catalogues what is and is not protected, identifies known gaps in the current
 implementation, and outlines future mitigations.
 
@@ -41,7 +41,7 @@ state-level adversary).
 **What they can do:**
 
 - Attempt TLS 1.3 MITM: TLS 1.3 prevents this if the client validates the
-  server's certificate. However, quicnprotochat currently uses **self-signed
+  server's certificate. However, quicproquo currently uses **self-signed
   certificates**, which means the client has no CA chain to verify. On the first
   connection, a MITM could present their own certificate and intercept the
   session (trust-on-first-use vulnerability).