fix(proxy): authenticate HTTP/HTTPS proxies via wwjs proxyAuthentication (#628)

[rmyndharis]

Summary

Fixes #628. On the whatsapp-web.js engine, a per-session proxy with a username/password never authenticated — only IP-authorized proxies worked.

Root cause

The adapter passed the whole proxy URL, credentials included, to Chromium via --proxy-server=<scheme>://user:pass@host:port. Chromium ignores credentials embedded in --proxy-server, and for SOCKS proxies it cannot authenticate at all. So an IP-authorized proxy (no credentials) worked, while a username/password proxy failed with an opaque Page.navigate timed out.

Changes

• Split the proxy URL into a credential-less --proxy-server value plus the username/password. The credentials are handed to whatsapp-web.js's built-in proxyAuthentication option, which drives Chromium's page.authenticate — the supported way to authenticate an HTTP/HTTPS proxy. Authenticated HTTP/HTTPS proxies now work.
• SOCKS proxies with credentials now log a clear warning ("Chromium cannot authenticate SOCKS proxies; use an IP-authorized proxy or an HTTP/HTTPS proxy") instead of failing with an opaque navigation timeout. This is a Chromium limitation (SOCKS proxy authentication is unsupported), not something the gateway can work around.
• Removed the cosmetic double-scheme (socks5://socks5://…) in the proxy log; it now logs the actual credential-less server.

Notes

The credential parsing/splitting is extracted into a pure, unit-tested buildProxyLaunchConfig() helper (strips credentials from the server arg, URL-decodes them, and flags SOCKS-with-credentials) so the logic is covered without standing up a Chromium/Client mock.

Verification

• New unit tests for buildProxyLaunchConfig (HTTP creds → proxyAuthentication, URL-decoding, SOCKS-creds → flagged + no auth, credential-less untouched).
• Full backend suite green (1936 tests), lint and build clean.