chore: rename project quicnprotochat -> quicproquo (binaries: qpq)

Rename the entire workspace:
- Crate packages: quicnprotochat-{core,proto,server,client,gui,p2p,mobile} -> quicproquo-*
- Binary names: quicnprotochat -> qpq, quicnprotochat-server -> qpq-server,
  quicnprotochat-gui -> qpq-gui
- Default files: *-state.bin -> qpq-state.bin, *-server.toml -> qpq-server.toml,
  *.db -> qpq.db
- Environment variable prefix: QUICNPROTOCHAT_* -> QPQ_*
- App identifier: chat.quicnproto.gui -> chat.quicproquo.gui
- Proto package: quicnprotochat.bench -> quicproquo.bench
- All documentation, Docker, CI, and script references updated

HKDF domain-separation strings and P2P ALPN remain unchanged for
backward compatibility with existing encrypted state and wire protocol.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

docs/src/getting-started/certificate-lifecycle.md

@@ -1,6 +1,6 @@
 # Certificate lifecycle and CA-signed TLS
 
-This page describes how to use CA-issued certificates with quicnprotochat and how to think about certificate pinning, rotation, and lifecycle.
+This page describes how to use CA-issued certificates with quicproquo and how to think about certificate pinning, rotation, and lifecycle.
 
 For basic server TLS setup (self-signed certs, generation), see [Running the Server](running-the-server.md#tls-certificate-handling).
 
@@ -8,8 +8,8 @@ For basic server TLS setup (self-signed certs, generation), see [Running the Ser
 
 ## Current behaviour
 
-- **Server:** Uses a single TLS certificate and private key (DER format). If the files are missing and the server is not in production mode, it generates a self-signed certificate. Production mode (`QUICNPROTOCHAT_PRODUCTION=1`) requires existing cert and key files.
-- **Client:** Trusts exactly the roots in the file given by `--ca-cert` (or `QUICNPROTOCHAT_CA_CERT`). Typically this is the server's own certificate (pinning) or a CA that signed the server cert.
+- **Server:** Uses a single TLS certificate and private key (DER format). If the files are missing and the server is not in production mode, it generates a self-signed certificate. Production mode (`QPQ_PRODUCTION=1`) requires existing cert and key files.
+- **Client:** Trusts exactly the roots in the file given by `--ca-cert` (or `QPQ_CA_CERT`). Typically this is the server's own certificate (pinning) or a CA that signed the server cert.
 
 ---
 
@@ -20,7 +20,7 @@ To pin the server so the client only connects to that server:
 1. Copy the server's certificate file (e.g. `data/server-cert.der`) from the server (or your deployment).
 2. Use that file as the client's CA cert:
    ```bash
-   quicnprotochat --ca-cert /path/to/server-cert.der ...
+   qpq --ca-cert /path/to/server-cert.der ...
    ```
 3. The client will only accept a connection if the server presents that exact certificate (or a chain ending in it). No separate CA bundle is required.
 
@@ -43,12 +43,12 @@ To use a certificate issued by a public CA (e.g. Let's Encrypt):
      ```
 2. **Configure the server** to use those paths:
    ```bash
-   export QUICNPROTOCHAT_TLS_CERT=/etc/quicnprotochat/server-cert.der
-   export QUICNPROTOCHAT_TLS_KEY=/etc/quicnprotochat/server-key.der
+   export QPQ_TLS_CERT=/etc/quicproquo/server-cert.der
+   export QPQ_TLS_KEY=/etc/quicproquo/server-key.der
    ```
 3. **Configure the client** to trust the CA that signed the server cert. Use the CA’s certificate (or the CA bundle) as `--ca-cert`:
    ```bash
-   quicnprotochat --ca-cert /etc/ssl/certs/your-ca.der --server-name your.server.example ...
+   qpq --ca-cert /etc/ssl/certs/your-ca.der --server-name your.server.example ...
    ```
    The `--server-name` must match the certificate’s SAN (e.g. DNS name).
 
@@ -60,7 +60,7 @@ To use a certificate issued by a public CA (e.g. Let's Encrypt):
 
 - **Manual rotation:** Replace `server-cert.der` and `server-key.der` on disk, then restart the server. Clients that pin the new cert must be updated with the new cert file.
 - **Let’s Encrypt renewal:** After renewing (e.g. via certbot), convert the new cert and key to DER, replace the files, and restart the server. If clients use the CA cert (e.g. ISRG Root X1) as `--ca-cert`, they do not need updates when the server cert is renewed.
-- **OCSP / CRL:** The quicnprotochat server does not currently perform OCSP stapling or CRL checks. Revocation is handled by the client or by operational procedures (e.g. short-lived certs, rotation on compromise).
+- **OCSP / CRL:** The quicproquo server does not currently perform OCSP stapling or CRL checks. Revocation is handled by the client or by operational procedures (e.g. short-lived certs, rotation on compromise).
 
 ---
 
@@ -70,6 +70,6 @@ To use a certificate issued by a public CA (e.g. Let's Encrypt):
 |------------------|-------------|--------------------|
 | Pinned (single server) | Self-signed or any | Server’s cert file |
 | CA-issued | Let’s Encrypt (or other CA) | CA cert (or bundle) |
-| Production | Always use existing cert/key; set `QUICNPROTOCHAT_PRODUCTION=1` | CA or pinned server cert |
+| Production | Always use existing cert/key; set `QPQ_PRODUCTION=1` | CA or pinned server cert |
 
 For production, prefer either (a) certificate pinning with the server’s cert or (b) a CA-issued server cert with clients trusting the CA, and plan for rotation and restart (or future reload support).