Add REDIS_URL to [program:bot] to un-brick Neon idle gating (#468)

[jlunder00]

Summary

Completes #468. The Redis next-due gate added there was inert in the process that matters most: bot/message_handler.py's run_polling() is the primary target of the whole Neon-idle-spin-down fix (the polling loop ticks every ~30s regardless of activity), but [program:bot] in supervisord.conf never had REDIS_URL set — only [program:api] and [program:interactive-agent-layer] did.

Without REDIS_URL, shared.notify_due's fail-open design does exactly what it's documented to do: no Redis client → is_due() always returns True → every check runs unconditionally, same as before #468 shipped. This is fail-open working correctly, just against a supervisord config gap rather than a real Redis outage — no error, no crash, just a silently-inert optimization.

Fix

• Added REDIS_URL="redis://localhost:6379" to [program:bot]'s environment= line, matching [program:api] / [program:interactive-agent-layer] — points at the same supervisord-managed local Redis instance so bot and api share one due_queue.
• Verified every current caller of shared.notify_due (api/routes/internal.py, api/routes/anchors.py → [program:api]; bot/message_handler.py → [program:bot]) now has REDIS_URL. agent_pool_manager and mcp don't call notify_due — no change needed there. tether-premium no longer references notify_due at all (per the resolved "meeting" component design — nothing to fix there).
• Added tests/infra/test_supervisord_redis_env.py: parses supervisord.conf and fails if any notify_due-calling program is missing REDIS_URL, or if bot/api point at different Redis instances. Confirmed this test goes red against the pre-fix config (origin/dev) and green after the fix — it would have caught this gap in review without needing a running supervisord/Redis instance.

Fail-open confirmation

The [program:bot] REDIS_URL fix is config-only — no application code touched, so shared/notify_due.py's fail-open behavior (unconfigured Redis / connection errors → treat as due, never silently skip a real notification) is unaffected. Re-ran the full tests/shared/ fail-open suite — all green, confirming notifications still fire correctly if Redis is ever briefly unavailable; this change only makes the happy path actually gate as designed.

Follow-up commit: observability (log-once + startup self-check)

The regression test above catches this bug class in CI, but there was no runtime signal that made the missing REDIS_URL obvious — it hid through a whole investigation cycle before being caught by review. Added two small, logging-only changes:

• notify_due.log_startup_status(): each process (api's lifespan, bot's main()) logs once at boot whether REDIS_URL is configured — INFO if so, ERROR with an explicit "gating fails open in this process" message if not.
• _get_client() now logs the "REDIS_URL not configured" case once per process at ERROR (via the same mechanism), instead of every gated call logging its own WARNING — collapses what was effectively per-~30s-tick log spam into a single loud one-time signal.

No behavior change — logging only. Confirmed via 3 new tests (log-once-per-process, startup INFO/ERROR branches) plus the full existing fail-open suite, all still green.

Test plan

• tests/infra/test_supervisord_redis_env.py — 3 tests, confirmed red on origin/dev's supervisord.conf, green after the fix
• tests/shared/ (29 tests total now, incl. fail-open coverage from Gate notification checks on a Redis next-due cache to let Neon suspend #468 + 3 new observability tests) — all passing
• Full tests/api/ + tests/bot/ + tests/shared/ + tests/infra/ suite: 434 passed, 11 pre-existing failures unrelated to this change (stale venv missing claude_agent_sdk + one pre-existing async-cancellation flake in test_redis_pubsub.py, untouched by this PR)
• All CI checks green after the follow-up commit (re-verified)