fix: honor proxy env vars in whatsapp bridge

[dathtd119]

What does this PR do?

• Makes the Gateway WhatsApp bridge honor standard system proxy environment variables when connecting to WhatsApp via Baileys.
• This fixes WhatsApp pairing in environments where outbound network traffic must go through an HTTP(S) proxy. Without this, pairing can fail before the QR code appears, repeatedly disconnecting with reason 408.

Related Issue

#43603

Type of Change

- [x] 🐛 Bug fix (non-breaking change that fixes an issue)
- [x] ✨ New feature (non-breaking change that adds functionality)
- [ ] 🔒 Security fix
- [ ] 📝 Documentation update
- [ ] ✅ Tests (adding or improving test coverage)
- [ ] ♻️ Refactor (no behavior change)
- [ ] 🎯 New skill (bundled or hub)

Changes Made

- Updated scripts/whatsapp-bridge/bridge.js
  - Reads standard proxy environment variables:
    - HTTPS_PROXY
    - https_proxy
    - HTTP_PROXY
    - http_proxy
  - Creates an HttpsProxyAgent when a proxy variable is present.
  - Passes the proxy agent into Baileys makeWASocket() via the agent option.
  - Logs when the WhatsApp bridge is using a proxy, without changing behavior when no proxy is configured.

- Updated scripts/whatsapp-bridge/package.json
  - Adds https-proxy-agent as a WhatsApp bridge dependency.

- Updated scripts/whatsapp-bridge/package-lock.json
  - Locks the new dependency and its transitive dependency metadata.

How to Test

1. From a machine or shell where outbound network traffic requires an HTTP(S) proxy, set one of the standard proxy environment variables:

   bash
   export HTTPS_PROXY=http://proxy-host:proxy-port
or:
   export https_proxy=http://proxy-host:proxy-port
or:
   export HTTP_PROXY=http://proxy-host:proxy-port
or:
   export http_proxy=http://proxy-host:proxy-port


2. Install/check WhatsApp bridge dependencies and validate syntax:

   bash
   cd scripts/whatsapp-bridge
   npm install
   node --check bridge.js
   npm list https-proxy-agent --depth=0


3. Start WhatsApp pairing:

   bash
   WHATSAPP_DEBUG=true node bridge.js --pair-only --session /tmp/hermes-wa-proxy-test


4. Confirm the bridge detects proxy configuration and reaches the QR-code pairing step:

   text
   Using proxy for WhatsApp WebSocket: ...
   Scan this QR code with WhatsApp on your phone:


5. Optional full Hermes flow:

   bash
   hermes whatsapp
   hermes gateway


   Expected result:
   - hermes whatsapp reaches QR-code pairing instead of looping with Connection closed (reason: 408).
   - After scanning the QR code, hermes gateway can connect to WhatsApp normally.

Checklist

<!-- Complete these before requesting review. -->

Code

- [ ] I've read the Contributing Guide
- [x] My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
- [x] I searched for existing PRs to make sure this isn't a duplicate
- [x] My PR contains only changes related to this fix/feature (no unrelated commits)
- [ ] I've run pytest tests/ -q and all tests pass
- [ ] I've added tests for my changes (required for bug fixes, strongly encouraged for features)
- [x] I've tested on my platform: Ubuntu Linux

Documentation & Housekeeping

<!-- Check all that apply. It's OK to check "N/A" if a category doesn't apply to your change. -->

- [x] I've updated relevant documentation (README, docs/, docstrings) — N/A
- [x] I've updated cli-config.yaml.example if I added/changed config keys — N/A
- [x] I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
- [x] I've considered cross-platform impact (Windows, macOS) per the compatibility guide
- [x] I've updated tool descriptions/schemas if I changed tool behavior — N/A

##For New Skills

<!-- Only fill this out if you're adding a skill. Delete this section otherwise. -->

N/A — this PR does not add or change a skill.

Screenshots / Logs

Before this change, WhatsApp pairing in a proxied environment could loop before displaying a QR code:

text
Connection closed (reason: 408). Reconnecting in 3s...
Connection closed (reason: 408). Reconnecting in 3s...
Connection closed (reason: 408). Reconnecting in 3s...


After this change, the bridge detects the configured proxy and usable

[alt-glitch]

Duplicate of #12787 — that PR ("feat(whatsapp): proxy support for the Baileys bridge") is the earlier open PR touching the same three files (scripts/whatsapp-bridge/bridge.js, package.json, package-lock.json) with the same approach: pass an HttpsProxyAgent into Baileys makeWASocket() when an HTTP(S) proxy env var is set. Both fix the same reason-408 pairing loop reported in #43603. See also #21627, which takes the opposite approach (stripping proxy vars from the bridge subprocess to force direct egress). Maintainers can pick whichever direction they prefer.

[austinpickett]

Closing in favour of #43822 (kyssta-exe), which the team is using as the canonical proxy implementation for this feature cluster.

Why #43822 was preferred over this PR:

• Uses PROXY_AGENT (ALL_CAPS) consistent with neighbouring env-var constants, while this PR mixes PROXY_URL + proxyAgent naming styles
• Places the proxy block in the env-var section rather than hoisting it above the CLI arg parsing block
• Includes the tracking issue reference

The package-lock.json addition here is a nice touch, but it was determined to be better regenerated after merge to avoid conflicts with the simultaneous Baileys rc13 bump in #43840.

Thank you for the contribution! 🙏