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/roadmap/milestones.md

@@ -1,6 +1,6 @@
 # Milestone Tracker
 
-This page tracks the project milestones for quicproquo, from initial transport
+This page tracks the project milestones for quicprochat, from initial transport
 layer through post-quantum cryptography. Each milestone produces production-ready,
 tested, deployable code -- see [Coding Standards](../contributing/coding-standards.md)
 for what that means in practice.
@@ -29,13 +29,13 @@ typed Cap'n Proto frames.
 **Deliverables:**
 
 - `schemas/envelope.capnp`: `Envelope` struct with `MsgType` enum (Ping/Pong at this stage)
-- `quicproquo-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
+- `quicprochat-proto`: `build.rs` invoking `capnpc`, generated type re-exports,
   canonical serialisation helpers
-- `quicproquo-core`: Ed25519 identity keypair generation,
+- `quicprochat-core`: Ed25519 identity keypair generation,
   Cap'n Proto frame codec (Tokio `Encoder`/`Decoder`)
-- `quicproquo-server`: QUIC listener with TLS 1.3 (quinn/rustls), Ping to Pong
+- `quicprochat-server`: QUIC listener with TLS 1.3 (quinn/rustls), Ping to Pong
   handler, one tokio task per connection
-- `quicproquo-client`: connects over QUIC, sends Ping, receives Pong, exits 0
+- `quicprochat-client`: connects over QUIC, sends Ping, receives Pong, exits 0
 - Integration test: server and client in same test binary using `tokio::spawn`
 - `docker-compose.yml` running the server
 
@@ -54,10 +54,10 @@ via Cap'n Proto RPC.
 
 - `schemas/auth.capnp`: `AuthenticationService` interface (`uploadKeyPackage`,
   `fetchKeyPackage`)
-- `quicproquo-core`: Ed25519 identity keypair generation, MLS KeyPackage
+- `quicprochat-core`: Ed25519 identity keypair generation, MLS KeyPackage
   generation via `openmls`
-- `quicproquo-server`: AS RPC server with `DashMap` store, atomic consume-on-fetch
-- `quicproquo-client`: `register-state` and `fetch-key` CLI subcommands
+- `quicprochat-server`: AS RPC server with `DashMap` store, atomic consume-on-fetch
+- `quicprochat-client`: `register-state` and `fetch-key` CLI subcommands
 - Integration test: Alice uploads KeyPackage, Bob fetches it, fingerprints match
 
 **Tests:** auth\_service.rs integration tests (upload, fetch, consume semantics).
@@ -97,7 +97,7 @@ group\_id lifecycle, MLS integration.
 3. **openmls 0.5 API gotchas.** Several `openmls` methods changed signatures
    between 0.4 and 0.5 (e.g., `MlsGroup::new` vs `MlsGroup::new_with_group_id`,
    `BasicCredential::new` taking `Vec<u8>` directly). These differences are
-   documented inline in `quicproquo-core/src/group.rs`.
+   documented inline in `quicprochat-core/src/group.rs`.
 
 **Branch:** `feat/m1-noise-transport`
 
@@ -142,13 +142,13 @@ providing post-quantum confidentiality for all group key material.
 
 **Deliverables:**
 
-- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicproquo-core`
+- Custom `OpenMlsCryptoProvider` with hybrid KEM in `quicprochat-core`
 - Hybrid shared secret derivation:
 
   ```
   SharedSecret = HKDF-SHA256(
     ikm  = X25519_ss || ML-KEM-768_ss,
-    info = "quicproquo-hybrid-v1",
+    info = "quicprochat-hybrid-v1",
     len  = 32
   )
   ```