fix(whatsapp-bridge): implement dynamic WhatsApp version resolution

[lucaslokchan]

What does this PR do?

Fixes WhatsApp bridge pairing failures caused by a stale WA Web protocol version.

startSocket() in scripts/whatsapp-bridge/bridge.js previously resolved the version only via fetchLatestBaileysVersion(). When WhatsApp bumps their Web client version, the Baileys-packaged version can lag. WhatsApp then rejects the WebSocket handshake with HTTP 405 (Method Not Allowed), and the bridge reconnects in a loop without completing QR pairing.

This PR adds resolveWaVersion() which prefers fetchLatestWaWebVersion() (live WhatsApp Web version) and falls back to fetchLatestBaileysVersion() if the live fetch fails. This matches the upstream Baileys workaround (#2731) and fixes #73700.

• Added a new function resolveWaVersion to fetch the latest WhatsApp Web version and fallback to the latest Baileys version if necessary.
• Updated the startSocket function to utilize the new version resolution logic, ensuring compatibility with the latest WhatsApp features.

Related Issue

Fixes #73700

Upstream: WhiskeySockets/Baileys#2731

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

• scripts/whatsapp-bridge/bridge.js
  • Import fetchLatestWaWebVersion from @whiskeysockets/baileys
  • Add resolveWaVersion() to fetch the live WA Web version, with fallback to fetchLatestBaileysVersion()
  • Update startSocket() to use resolveWaVersion() instead of calling fetchLatestBaileysVersion() directly

How to Test

1. Install bridge deps:

   cd scripts/whatsapp-bridge && npm install

2. (Optional) Use a fresh session if re-pairing:

   rm -rf ~/.hermes/platforms/whatsapp/session

3. Run pairing:

   hermes whatsapp

4. Confirm:
   • QR code appears (no immediate 405 / Connection Failure loop)
   • Bridge reaches connected after scan
   • curl http://127.0.0.1:<bridge-port>/health returns "status": "connected"
     Before: ⚠️ Connection closed (reason: 405). Reconnecting in 3s... — pairing never completes.
     After: bridge connects and pairing completes normally.

[teknium1]

Thanks for the focused pairing fix. Current main still obtains the socket version through fetchLatestBaileysVersion() at scripts/whatsapp-bridge/bridge.js:398, so this is not already implemented in Hermes.

Problems

• The new resolver branch at scripts/whatsapp-bridge/bridge.js:396-402 has no executable regression test; the current bridge tests do not reference either version helper, and gh pr checks 73795 reports no checks.
• This intentionally prefers the live WhatsApp Web revision. In the linked upstream discussion, a Baileys maintainer warns that this can diverge from the protocol revision Baileys has validated; upstream PR #2728 instead updated the revision used by the existing helper.

Suggested changes

• Extract and directly test the resolver's live-success and Baileys-fallback paths; avoid source-text tests.
• Add rationale for choosing the live-Web source over the upstream-maintained version source, or narrow the change to the upstream-approved path.

Automated hermes-sweeper review.

[teknium1]

Please add executable coverage for this fallback path as well as the isLatest live-version path. The bridge starts side effects at module load, so extract this resolver to a pure helper and test the helper directly rather than adding a source-text contract.

[lucaslokchan]

Addressed the test feedback in commit d993dbe412841f49e36942604729cb2e6cf6e52b:

• Moved resolveWaVersion to bridge_helpers.js (DI for the two fetch functions)

• Added tests for live-success and both Baileys-fallback paths in bridge.native.test.mjs

• All bridge Node tests pass locally