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/key-lifecycle.md

@@ -1,6 +1,6 @@
 # Key Lifecycle and Zeroization
 
-quicproquo uses multiple key types with different lifetimes, creation
+quicprochat 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/quicproquo-core/src/identity.rs`
+**Source:** `crates/quicprochat-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/quicproquo-core/src/keystore.rs` and
-`crates/quicproquo-core/src/group.rs`
+**Source:** `crates/quicprochat-core/src/keystore.rs` and
+`crates/quicprochat-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 quicproquo code but are critical to understanding the
+directly accessible in quicprochat 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:** quicproquo code interacts with epoch keys only
+- **No direct access:** quicprochat code interacts with epoch keys only
   indirectly through `send_message()` and `receive_message()`.
 
 ## Hybrid KEM Keys (Future -- M5+)
 
-**Source:** `crates/quicproquo-core/src/hybrid_kem.rs`
+**Source:** `crates/quicprochat-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