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/overview.md

@@ -1,6 +1,6 @@
 # Design Decisions Overview
 
-This section collects the Architecture Decision Records (ADRs) that document the key design choices in quicproquo. Each ADR follows a standard format: context (why the decision was needed), decision (what was chosen), and consequences (trade-offs, benefits, and residual risks).
+This section collects the Architecture Decision Records (ADRs) that document the key design choices in quicprochat. Each ADR follows a standard format: context (why the decision was needed), decision (what was chosen), and consequences (trade-offs, benefits, and residual risks).
 
 These decisions are not immutable. Each ADR has a status field and can be superseded by a later ADR if circumstances change. The goal is to preserve the reasoning behind each choice so that future contributors understand *why* the system works the way it does, not just *how*.
 
@@ -19,7 +19,7 @@ These decisions are not immutable. Each ADR has a status field and can be supers
 
 ## Design comparison
 
-For a broader comparison of quicproquo's design against alternative messaging protocols (Signal, Matrix/Olm/Megolm), see [Why This Design, Not Signal/Matrix/...](why-not-signal.md).
+For a broader comparison of quicprochat's design against alternative messaging protocols (Signal, Matrix/Olm/Megolm), see [Why This Design, Not Signal/Matrix/...](why-not-signal.md).
 
 ---
 
@@ -41,7 +41,7 @@ Each ADR page follows this structure:
 
 **Context**
 
-quicproquo v1 used Cap'n Proto for both serialisation and RPC dispatch via
+quicprochat v1 used Cap'n Proto for both serialisation and RPC dispatch via
 `capnp-rpc`. This worked well for the initial 8-method `NodeService` interface
 but had several limitations as the protocol expanded:
 
@@ -60,15 +60,15 @@ but had several limitations as the protocol expanded:
 
 **Decision**
 
-Replace `capnp-rpc` with a custom binary framing layer (`quicproquo-rpc`) and
+Replace `capnp-rpc` with a custom binary framing layer (`quicprochat-rpc`) and
 Protocol Buffers (`prost`) for payload serialisation:
 
 - Three frame types: Request (10-byte header), Response (9-byte header), Push
   (6-byte header), all carrying Protobuf-encoded payloads.
 - Method IDs are numeric `u16` constants dispatched via a handler registry.
   One QUIC bidirectional stream per RPC call; push events on QUIC uni-streams.
-- ALPN changed from `b"capnp"` to `b"qpq"`. Default port changed from 7000 to 5001.
-- Cap'n Proto legacy types are retained in `quicproquo-proto` for v1 compatibility
+- ALPN changed from `b"capnp"` to `b"qpc"`. Default port changed from 7000 to 5001.
+- Cap'n Proto legacy types are retained in `quicprochat-proto` for v1 compatibility
   but are no longer used for RPC dispatch.
 
 **Consequences**
@@ -90,9 +90,9 @@ Costs:
 
 **Code references**
 
-- Frame format: `crates/quicproquo-rpc/src/framing.rs`
-- Method IDs: `crates/quicproquo-proto/src/lib.rs` (`method_ids` module)
-- Proto schemas: `proto/qpq/v1/*.proto`
+- Frame format: `crates/quicprochat-rpc/src/framing.rs`
+- Method IDs: `crates/quicprochat-proto/src/lib.rs` (`method_ids` module)
+- Proto schemas: `proto/qpc/v1/*.proto`
 
 ---
 
@@ -109,7 +109,7 @@ ADR-004 and ADR-005 reflect a design philosophy where the server does as little
 ### Schema-first design
 
 The v2 protocol defines all messages and method IDs in checked-in source files
-(`proto/qpq/v1/*.proto` and `crates/quicproquo-proto/src/lib.rs`). Every wire
+(`proto/qpc/v1/*.proto` and `crates/quicprochat-proto/src/lib.rs`). Every wire
 type is documented, versioned, and evolvable through the standard Protobuf
 schema evolution rules (adding optional fields, reserving removed field numbers).