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/design-rationale/adr-004-mls-unaware-ds.md

@@ -40,7 +40,7 @@ The RFC explicitly envisions that the DS operates on opaque blobs, not on decryp
 
 ## Decision
 
-The quicproquo Delivery Service is **MLS-unaware**. It routes opaque byte strings by `(recipientKey, channelId)` without parsing, inspecting, or validating any MLS content.
+The quicprochat Delivery Service is **MLS-unaware**. It routes opaque byte strings by `(recipientKey, channelId)` without parsing, inspecting, or validating any MLS content.
 
 ### What the DS sees
 
@@ -109,8 +109,8 @@ This means that sending a message to a group of n members requires n-1 enqueue c
 |---|---|
 | `schemas/delivery.capnp` | DeliveryService RPC interface (opaque `Data` payloads) |
 | `schemas/node.capnp` | NodeService: `enqueue`, `fetch`, `fetchWait` methods |
-| `crates/quicproquo-server/src/storage.rs` | Server-side queue storage (DashMap-based FIFO queues) |
-| `crates/quicproquo-server/src/main.rs` | NodeService RPC handler implementation |
+| `crates/quicprochat-server/src/storage.rs` | Server-side queue storage (DashMap-based FIFO queues) |
+| `crates/quicprochat-server/src/main.rs` | NodeService RPC handler implementation |
 
 ---