fix(relay): warn when BUZZ_RELAY_URL is set but RELAY_URL is not

[Yyunozor]

Summary

The relay reads only RELAY_URL (crates/buzz-relay/src/config.rs).
BUZZ_RELAY_URL is the agent-side connection target — used by buzz-acp,
docs/remote-agents.md, and .env.example — and most relay variables are
BUZZ_-prefixed, so BUZZ_RELAY_URL is a name an operator can reasonably
expect the relay itself to read too. When it's set instead of RELAY_URL,
relay_url silently falls back to ws://localhost:3000, the deployment
community is provisioned bound to that host, and every real request 404s
with no community is configured for this host — the only signal is a
startup log line easy to miss among healthy-looking ones (as reported in
#6764).

This adds a startup warning for that specific mismatch: BUZZ_RELAY_URL set
and RELAY_URL not set. It follows the existing inert_env_vars pattern in
the same file — a pure helper takes an injected env lookup so the predicate
tests don't touch process env.

A second, related bug: when BUZZ_REQUIRE_RELAY_MEMBERSHIP=true and the
host can't be derived, the fatal error in main.rs names BUZZ_RELAY_URL,
but the value it prints (config.relay_url) actually comes from
RELAY_URL. An operator debugging that crash is sent to the wrong
variable — the error now names RELAY_URL, the variable whose value it
prints. One-line fix, same file.

Does not add BUZZ_RELAY_URL as an accepted alias (option 2 in the issue)
— that changes runtime behavior and is left as a maintainer-directed
follow-up.

Known limitation: this covers only the process-env misconfiguration
reported in the issue. It does not cover a compose file or other setup
where both variables end up set to different hosts.

Related issue

Fixes #6764. Credit to @morven-ai for the diagnosis (traced it to
router.rs's tenant-host resolution) and for suggesting this exact
warning as the first of three options. They also offered to send a PR for it;
happy to close this one if they would rather send theirs.

Searched for a competing PR: none references #6764 (0 comments, 0
assignees, one unrelated cross-reference). Closest open PR: #7793 also adds
a log-capture helper to the config.rs tests; if it lands first, I'll
rebase onto its helper.

Testing

cargo fmt --check
cargo clippy -p buzz-relay --all-targets -- -D warnings
cargo test -p buzz-relay config -- --test-threads=1

All three pass clean (82 config tests, 0 failed, 2 ignored — Postgres-only).
--test-threads=1 is needed for a pre-existing, unrelated race: some test
helpers elsewhere in the crate call Config::from_env() without holding
ENV_MUTEX, so they can observe a concurrently-running writer test
mid-mutation. Reproduced live on this branch (parallel run, same filter,
5 tries): 1 run failed with 7 unrelated assertion panics
(api::admin, api::gifs, config::tests::valid_relay_owner_pubkey_...),
4 runs passed clean. PR #6265 (open, unmerged) targets this same gap
crate-wide.

Two of the new tests drive the real Config::from_env() startup path
(not just the pure helper), with tracing captured the same way
config_with_admin_env_capturing_logs does. Note: config::tests is in no
CI test selector today (the Justfile selects nip_fi_config::tests:: but not
config::tests::), so these tests run locally only.

Also ran the actual binary (cargo build --release -p buzz-relay, no
Docker services, no private key configured — so this exercises the config
warning itself, not the full boot):

$ env -u RELAY_URL BUZZ_RELAY_URL=wss://relay.example.test RUST_LOG=buzz_relay=info,warn ./target/release/buzz-relay
...
{"level":"WARN","message":"BUZZ_RELAY_URL is set but the relay reads RELAY_URL; ...","target":"buzz_relay::config"}
...
Error: BUZZ_RELAY_PRIVATE_KEY must be set. Run `just bootstrap` for local development...

The warning fires exactly once during config load, before the process
exits at key load (no key configured in this minimal run, so it never
reaches the Config loaded line). With RELAY_URL set instead, the same
run produces no such warning. A full end-to-end run against a live local
relay (just bootstrap && just setup) is still owed as a human
confirmation step before merge.

[github-actions]

🔐 Codex Security Review

Status: review required for the current range.

The current range is b0d6fb8ad27f6f255a5044e49ed0a59e11542914...fd4bc63326880c026c183528ed84dbbbf9ab415f.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review fd4bc63326880c026c183528ed84dbbbf9ab415f to authorize a new review.
Any previous review applies only to its recorded range.