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/contributing/coding-standards.md

@@ -1,6 +1,6 @@
 # Coding Standards
 
-This page defines the engineering standards for quicproquo. These are
+This page defines the engineering standards for quicprochat. These are
 non-negotiable -- all code merged into the repository must conform to these
 rules. The standards exist to ensure that every milestone produces
 production-ready, auditable, and secure code.
@@ -85,9 +85,9 @@ pub fn create_group(
 
 - No `unwrap()` or `expect()` on cryptographic operations or I/O in non-test
   paths. All crypto errors must be typed and propagated.
-- Use `thiserror` for library error types (`quicproquo-core`,
-  `quicproquo-proto`, `quicproquo-rpc`, `quicproquo-sdk`) and `anyhow` for
-  application-level error handling (`quicproquo-server`, `quicproquo-client`).
+- Use `thiserror` for library error types (`quicprochat-core`,
+  `quicprochat-proto`, `quicprochat-rpc`, `quicprochat-sdk`) and `anyhow` for
+  application-level error handling (`quicprochat-server`, `quicprochat-client`).
 - `unwrap()` is acceptable only in:
   - Test code.
   - Cases where the invariant is provably guaranteed by the type system