feat(relay): make Redis pool size configurable, default 16

[tlongwell-block]

Why

bb-public relay pods started showing Redis pool waiters today (buzz_redis_pool_waiting peaked at 2, buzz_redis_pool_available min 1) at ~190 events/s — first waiters since launch day.

Root cause: we never configure the deadpool-redis pool size, so it uses deadpool's default of CPU_COUNT * 2. On a 2-vCPU relay pod that's 4 connections, shared by rate-limit checks, presence, pub/sub publishes, NIP-98 replay guard, and cache invalidation. Confirmed live: every bb-public pod reports buzz_redis_pool_max = 4.

What

• New BUZZ_REDIS_POOL_SIZE env var (relay), default 16 when unset; zero/unparsable values fall back to the default.
• Wired into the single shared pool built in main.rs (the only production pool construction; test-only pools untouched).
• .env.example documents it.

Minimal by design: 16 per pod × 5 pods = 80 Redis connections vs ElastiCache's 65k ceiling — noise for the server, but 4× more headroom where the waiters showed up. No chart change needed; ops can tune per-deploy via env.

Testing

• New config test: env override (32), zero → fallback, junk → fallback; defaults_are_valid asserts the 16 default.
• cargo test -p buzz-relay: 735 passed, 1 failed — api::mesh_demo::tests::demo_join_forwarded_arm_round_trips_echo, which fails identically on clean origin/main at the same SHA (pre-existing, known flake).
• cargo clippy -p buzz-relay --all-targets clean, cargo fmt clean.

Observability

Watch block.buzz_relay.buzz_redis_pool_max flip 4 → 16 on rollout, and buzz_redis_pool_waiting stay at 0.