fix(deploy): add Tauri webview origins to the compose BUZZ_CORS_ORIGINS default

[nscheifler]

Summary

The compose template deploy/compose/.env.example sets BUZZ_CORS_ORIGINS to one public domain. The webview of the desktop app has a different origin. The origin is tauri://localhost on macOS and Linux. The origin is http://tauri.localhost on Windows.

The relay reads BUZZ_CORS_ORIGINS as a comma-separated list of exact origins (crates/buzz-relay/src/config.rs; build_cors_layer in crates/buzz-relay/src/router.rs). When the variable is set, the relay does not permit other origins. This design is correct, but the template value does not include the webview origins. Thus the desktop app cannot use the HTTP API of a relay that an operator deploys from the template.

The first failure that the user sees is in the "Join an existing community" flow. The flow stops and shows the error Load failed. At the same time, the relay replies correctly to a NIP-11 request from curl. Thus the relay seems healthy, and the CORS cause is hard to find.

This change:

• Adds the two webview origins to the default value of BUZZ_CORS_ORIGINS in deploy/compose/.env.example.
• Adds a comment to the same file. The comment tells the operator to keep the webview origins when they set their own domain.
• Adds a note with the same requirement to the "Production notes" section of deploy/compose/README.md.

Related issue

Fixes #2872.

The closest existing PRs (not duplicates):

• docs: document BUZZ_CORS_ORIGINS and Tauri webview origins in .env.example #2617 adds comments about BUZZ_CORS_ORIGINS to the root .env.example. It does not change the value in the compose template. The two changes are compatible.
• fix(desktop): fetch join policies through native networking #2862 moves the join-policy fetch to native networking. The invite and moderation calls stay in the webview. Thus the compose template must continue to supply the webview origins.

Testing

This is a change to a template and a document only. No code paths change, so there are no new tests.

We did the test on a live deployment: Buzz Desktop v0.4.26 on macOS, relay deployed with deploy/compose and Caddy TLS.

1. Deploy the relay with the unmodified template value. The join flow fails with the error Load failed.
2. Add tauri://localhost,http://tauri.localhost to BUZZ_CORS_ORIGINS. Restart the relay.
3. Do the join flow again. The desktop app joins the community correctly.

[quentindecock]

Independently hit this on Desktop 0.5.0 (report above was 0.4.26) and can confirm the fix. One addition: the impact is broader than "Join an existing community" — it also breaks invite minting from the desktop app.

mintInvite() in desktop/src/shared/api/invites.ts is one of the few paths that calls the relay via the webview's fetch() rather than the Rust HTTP client, so it's the only place CORS applies. Everything else — /events, /query, the WebSocket — bypasses it entirely, which makes this fail in a confusing way: chat works perfectly while one button silently doesn't.

Concrete symptom, with BUZZ_CORS_ORIGINS set only to the relay's own origin:

$ curl -i -X OPTIONS -H 'Origin: tauri://localhost' \
    -H 'Access-Control-Request-Method: POST' \
    -H 'Access-Control-Request-Headers: authorization,content-type' \
    https://<relay>/api/invites
HTTP/2 200
access-control-allow-methods: *
access-control-allow-headers: *
# no access-control-allow-origin

Preflight returns 200 but omits Access-Control-Allow-Origin, so the webview blocks it, fetch() throws before sending, and the relay logs nothing at all — I confirmed zero POST /api/invites requests with tower_http=debug. The UI shows only "Couldn't copy the invite link", because the catch wraps both the mint and the clipboard write. Adding the two origins fixed it immediately.