Relay cannot be served under a path prefix — hardcoded root routes block deployment behind a path-routing gateway

## Problem

`buzz-relay` mounts every route at the root. The WebSocket upgrade and the NIP-11 document both live on `/` (`crates/buzz-relay/src/router.rs:64`), with the rest of the HTTP surface as siblings. There is no configuration to serve the relay under a path prefix — the only `nest()` call in `build_router` is for the admin sub-router.

That makes the relay undeployable behind a gateway that routes to apps by path rather than by hostname. Such gateways are common in shared-ingress Kubernetes setups: each app is assigned a path prefix, auth policy is applied per prefix, and the root is not available to any individual app. A relay that can only serve at `/` has no place to go.

Compose behind a dedicated hostname works, so this is not a blocker for every self-hoster — but anyone whose ingress is path-routed currently has no option except a fork.

## Proposal

Add a `BUZZ_BASE_PATH` config option (empty by default, so current behavior is unchanged). When set, nest the merged router under that prefix so the WebSocket lands at `wss://host/` and every HTTP route under `wss://host//...`.

Health probes (`/health`, `/_liveness`, `/_readiness`) should stay mounted at the root as well, since Kubernetes probes hit the pod directly rather than through the gateway.

## Things to get right

- **NIP-98 `u` tags** — auth events sign the full request URL, and the server compares against the URL it received. The prefix has to be present consistently on both sides or auth fails in a way that looks like a signature bug.
- **Client-side URL derivation** — `relayHttpFromWs` (`desktop/src/shared/api/inviteHelpers.ts:80`) is a pure scheme swap, so a prefix carries through. `mediaUrl.ts:49` compares `new URL().origin`, which drops the path — still matches, just coarser. `buzz-cli` and the mobile client need the same audit.
- **Git smart HTTP** and the static web assets, both of which build URLs of their own.
- Nostr relay URLs may carry a path, so `wss://host/relay` is protocol-legal — no NIP-level obstacle.

## Willing to implement

Happy to open a PR if the approach and the config name look right.