[Bug] buzz-admin silently falls back to hardcoded dev database credentials when DATABASE_URL is unset

Summary

buzz-admin does not load .env and, when DATABASE_URL is absent from the process environment, silently falls back to a hardcoded development connection string with default credentials. In crates/buzz-admin/src/main.rs:

rust
let db_url = std::env::var("DATABASE_URL")
.unwrap_or_else(|_| "postgres://buzz:buzz_dev@localhost:5432/buzz".to_string());

The relay loads .env before starting, so a self-hosted deployment with hardened credentials runs fine — until buzz-admin migrate is invoked from a context that doesn't export .env (e.g. an update script calling cargo run -p buzz-admin -- migrate). It then fails with:

error: database error: error returned from database: password authentication failed for user "buzz"

The asymmetry (relay reads .env, buzz-admin doesn't) makes this confusing to debug: the running system is healthy while migrations fail with an auth error that suggests a corrupted config rather than an unread one.

Reproduction
Self-hosted relay per the README, with the Postgres password in .env changed from the default.
Run cargo run -p buzz-admin -- migrate from a shell that has not sourced .env.
Migration fails with password authentication failed for user "buzz" — buzz-admin attempted the hardcoded buzz_dev credentials instead of failing on missing configuration.

Verified on v0.4.24 and v0.4.25 (crates/buzz-admin/ unchanged between the two).

Expected behavior

Either of:

buzz-admin loads .env the same way the relay does, so both binaries read configuration from the same source; or
buzz-admin fails hard with a clear message ("DATABASE_URL is not set") instead of silently trying default credentials.
Why the silent fallback is worth fixing (not just documenting)

Falling back to known default credentials without any warning has a security smell beyond the confusing UX: an operator who sees migrations "work" has no signal that the tool connected with dev defaults rather than their configured credentials. Combined with the dev docker-compose.yml defaults, a deployment that drifts back to defaults can end up running Postgres with a publicly known password. Failing loudly on missing configuration would surface such drift immediately.

Happy to provide more environment details if useful.

Start in crates/buzz-admin/src/main.rs and run cargo run -p buzz-admin -- migrate from a shell that has not sourced .env to reproduce the fallback. Compare its configuration behavior with the relay described in the issue; done means buzz-admin uses the configured DATABASE_URL source or exits with a clear missing-configuration error instead of trying hardcoded credentials.

Written by the indexing model from the issue text.