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-002-capnproto.md

@@ -6,7 +6,7 @@
 
 ## Context
 
-quicproquo needs an efficient, typed wire format for client-server communication. The format must support:
+quicprochat needs an efficient, typed wire format for client-server communication. The format must support:
 
 1. **Typed messages** with compile-time schema enforcement to eliminate hand-rolled serialisation bugs.
 2. **Schema evolution** so that new fields and methods can be added without breaking existing clients.
@@ -105,7 +105,7 @@ The Cap'n Proto schemas are stored in the `schemas/` directory:
 
 ### Costs and trade-offs
 
-- **Build-time code generation.** The `capnpc` compiler must run during the build (via `build.rs` in `quicproquo-proto`). This adds a build dependency and increases compile times slightly.
+- **Build-time code generation.** The `capnpc` compiler must run during the build (via `build.rs` in `quicprochat-proto`). This adds a build dependency and increases compile times slightly.
 - **Learning curve.** Cap'n Proto's builder/reader API is different from typical `serde`-based Rust serialisation. Developers must learn the Cap'n Proto programming model (builders for construction, readers for traversal, owned messages for storage).
 - **Generated code verbosity.** The generated Rust code is verbose and not intended to be read directly. Application code interacts with it through the builder/reader traits.
 - **Smaller ecosystem than Protobuf.** Cap'n Proto has fewer users, fewer tutorials, and fewer third-party tools than Protobuf. However, the core Rust crates are well-maintained.
@@ -114,7 +114,7 @@ The Cap'n Proto schemas are stored in the `schemas/` directory:
 ### Residual risks
 
 - **Crate maintenance.** The `capnp` and `capnp-rpc` crates are maintained primarily by David Renshaw. If maintenance lapses, the project would need to fork or switch serialisation formats. Mitigated by the crates' maturity and the relatively stable Cap'n Proto specification.
-- **RPC limitations.** The Rust `capnp-rpc` crate implements Level 1 of the Cap'n Proto RPC protocol. Level 3 features (three-party handoffs) are not supported. This has not been a limitation for quicproquo's client-server architecture.
+- **RPC limitations.** The Rust `capnp-rpc` crate implements Level 1 of the Cap'n Proto RPC protocol. Level 3 features (three-party handoffs) are not supported. This has not been a limitation for quicprochat's client-server architecture.
 
 ---
 
@@ -126,8 +126,8 @@ The Cap'n Proto schemas are stored in the `schemas/` directory:
 | `schemas/auth.capnp` | AuthenticationService RPC interface |
 | `schemas/delivery.capnp` | DeliveryService RPC interface |
 | `schemas/node.capnp` | NodeService unified RPC interface |
-| `crates/quicproquo-proto/build.rs` | Build script that invokes `capnpc` for code generation |
-| `crates/quicproquo-proto/src/lib.rs` | Re-exports generated Cap'n Proto modules |
+| `crates/quicprochat-proto/build.rs` | Build script that invokes `capnpc` for code generation |
+| `crates/quicprochat-proto/src/lib.rs` | Re-exports generated Cap'n Proto modules |
 
 ---