fix(whatsapp-gateway): IQ probe passes single JID, not a list

[retog]

Problem

After the #115 health-wedge fix + instance update, /health reports the WhatsApp bridge as not connected with:

bridge link is up but info queries (usync) are failing … expected JID got list

That message is not a real usync timeout — it is a type error in the probe itself. The IQ probe calls the device-lookup with a list:

fn([own_jid])   # get_user_info / get_user_devices

The installed neonize build wants a single JID and rejects the list. So the probe raises every cycle, and the loop cannot distinguish that TypeError from a genuine wedge. Two consequences:

1. False negative health — iq_ok=False / connected=false even when the bridge can send. This is why the /gateways page and /health disagree.
2. Self-inflicted churn — on each "wedge" the loop tears the connection down to force a reconnect (_maybe_iq_reconnect). A bridge reconnected on every probe interval also fails real sends' own usync device resolution — the "usync timed out" failures seen when sending to a first-contact recipient.

Fix

Pass a single JID, falling back to the list form on TypeError, mirroring the existing build_jid() version adapter — robust across neonize argument-shape changes.

Verifies

• ast.parse clean.
• Diagnosed live: /health error string matches line 970 exactly; send path (_to_jid→build_jid→send_message) is correct and unaffected.

Follow-up to #115. 🤖 Generated with Claude Code

[aros-agent]

Written by Aros, the project's AI agent, from my own account @aros-agent.

This looks fully superseded by #119 (merged 2026-08-16T19:19:20Z), and safe to close. Verified from the content of main's scripts/whatsapp-gateway.py rather than from either PR's badges:

• _iq_probe_once on main already tries the scalar shape first and falls back to the list form — the entirety of this PR's change — via the (method, style) candidate loop.
• It goes further than this diff in two ways that matter for the exact failure quoted in this PR's body: shape errors are classified by _is_call_shape_error, which matches TypeError or the protobuf message ("parameter to initialize message field"), so the classification doesn't depend on which exception class the installed protobuf raises — this diff's bare except TypeError would miss the message-only case; and the first working (method, shape) is cached in _iq_call, so a later exception is never re-classified as a shape issue and a genuine usync timeout still raises.
• The CONFLICTING state here is fix(whatsapp): correct IQ-probe call shape; show pairing QR only when re-pairing helps #119 rewriting the same lines (the fn([own_jid]) call at old line 970 no longer exists on main).

Nothing in this diff is absent from main, so closing loses nothing. Closing is yours to do — it's your PR.

[retog]

Covered by 119