fix(buzz-acp): make resolved relay URL authoritative for ACP child sp…

[azhodl]

…awns

A child spawned by AcpClient::spawn inherited the parent environment and only received persona env vars under operator-wins semantics, so with a missing or stale parent BUZZ_RELAY_URL it silently fell back to the ws://localhost:3000 default and died with "404 no community for this host" after consuming the mention. The mention is lost: the harness has already taken the work, and the child never reaches the relay to reply.

This is reachable whenever the operator passes --relay-url without also exporting BUZZ_RELAY_URL, which the flag's existence invites.

• config.rs: Config::from_args pushes the resolved relay URL (CLI over env over default, per clap) into persona_env_vars, so every pool spawn/respawn path carries it. Preflight: an unparseable relay URL now fails terminally (missing-config) before the harness subscribes or takes work; the error prints only the URL, never keys.
• acp.rs: AcpClient::spawn force-sets BUZZ_RELAY_URL from extra_env, overriding both missing and stale parent env. All other keys keep operator-wins semantics.
• Tests: child-env probe for unset-parent and stale-parent scenarios; full-chain CLI-to-PoolStartup extra_env test; missing-config preflight test.

No unsafe. New unwrap()/expect() calls are confined to #[cfg(test)] modules.

Summary

Related issue

Testing

[Chessing234]

the new spawn test mutates the real BUZZ_RELAY_URL process-wide, and config.rs — a file this PR also edits — writes down the opposite convention at :2766: "We pass the value via the CLI flag ... rather than std::env::set_var to avoid test-parallelism races on shared env state. The env-var wiring is covered by the clap #[arg(env)] attribute itself."

that matters more for this key than for the BUZZ_AUTH_TAG precedent you cite: BUZZ_RELAY_URL is declared at config.rs:240 with #[arg(env = "BUZZ_RELAY_URL", default_value = "ws://localhost:3000")], so any test in the binary that builds CliArgs through clap's env fallback while scenario 2 holds "http://localhost:3000" picks it up. cargo test runs these in parallel threads, so across the crate's ~776 tests that's a live flake vector rather than a theoretical one.

scenario 1 needs no mutation at all. scenario 2 needs it only because spawn reads std::env::var_os directly — taking that lookup as a parameter (defaulting to std::env::var_os) would make the stale-parent case testable without touching global state.