hermes - 💡(How to fix) Fix WhatsApp bridge connect timeout (~30s) is hardcoded — make it env-configurable for cold-start boots

Summary

The WhatsApp bridge connect timeout is hardcoded at ~30s in gateway/platforms/whatsapp.py with no env/config override. On a cold start (fresh host, first node bridge spin-up + WhatsApp WS handshake) this 30s is occasionally exceeded, so the first connect attempt logs an error and the platform is queued for retry. The reconnection watcher recovers ~30s later, so it's self-healing — but it produces a spurious ✗ whatsapp error: whatsapp connect timed out after 30s on every cold boot.

Where

gateway/platforms/whatsapp.py, in the bridge-bootstrap connect path:

• Phase 1 — wait for the bridge HTTP server: for attempt in range(15): await asyncio.sleep(1) (≈15s)
• Phase 2 — wait for status: connected: another ≈15s

Both bounds are literal constants (range(15)), unlike e.g. WHATSAPP_NPM_INSTALL_TIMEOUT / WHATSAPP_SEND_TIMEOUT_MS, which are env-configurable.

Repro

Provision a fresh host with a valid restored creds.json (so pre-flight passes), start the gateway. On a cold node/handshake the first attempt times out at 30s:

gateway.run: ✗ whatsapp error: whatsapp connect timed out after 30s
gateway.run: Gateway started with no connected platforms — 1 platform(s) queued for retry
gateway.run: Reconnecting whatsapp (attempt 2)...
gateway.run: ✓ whatsapp reconnected successfully

Ask

Make the connect timeout configurable via an env var (e.g. WHATSAPP_CONNECT_TIMEOUT / a Phase-1 + Phase-2 split), consistent with the other WHATSAPP_* timeout knobs. That lets cold-start/post-rebuild hosts avoid the spurious first-attempt error without patching source.

Environment

Hermes v0.15.1, Ubuntu 22.04, WhatsApp (Baileys) bridge, bot mode. Bridge node_modules already present (not an npm-install delay). Behaviour is reliably self-healing on attempt 2.