fix(compose): restore mobile pairing sidecar

[StephGlansberg]

What changed

• add an opt-in pairing Compose profile that runs buzz-pair-relay from the pinned relay image
• bind the sidecar to loopback with a configurable host port
• document the pairing relay URL and port in the Compose environment example

Why

Desktop QR pairing advertises /pair, but the local Compose stack did not run the pairing relay. Mobile clients therefore reached an HTTP 404 instead of a WebSocket upgrade. The profile is opt-in and does not alter the default relay stack.

Validation

• cargo test -p buzz-pair-relay — 51 integration tests passed
• docker compose ... --profile pairing config --quiet
• rendered service list includes pairing-relay
• git diff --check

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: baac881a96

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Route the advertised /pair URL to the sidecar

When an operator enables this suggested URL with the bundled TLS flow (BUZZ_COMPOSE_TLS=true), deploy/compose/Caddyfile still sends every request—including /pair—to relay:3000, while the new sidecar is only published on a loopback host port. Consequently NIP-11 advertises a pairing URL that never reaches pairing-relay, so mobile pairing continues to fail; add a Caddy /pair matcher that proxies to pairing-relay:5000 before the catch-all relay route.

Useful? React with 👍 / 👎.