Passive linked companion leaves the primary phone's calls stuck at "Connecting…" for some accounts (unlink instantly fixes it)

Since WhatsApp rolled out voice/video calling to web/companion sessions (#1202, GA around 2026-07-28 with phone↔web call transfer), we have two independent, user-confirmed cases where a purely passive whatsmeow companion breaks the primary phone's calls:

• WhatsApp text messages work fine in both directions.
• Every WhatsApp call — incoming AND outgoing, audio AND video — fails: the far end shows a running call timer while the account's own phone sits at "Connecting…" forever.
• Unlinking the whatsmeow device restores calling immediately. Re-linking breaks it again.
• One reporter made the A/B single-variable: everything else on the phone stayed identical (including another companion-style integration), only the whatsmeow link was toggled — calls followed the whatsmeow link exactly. Primary was an iPhone.

Our client is passive in the strictest sense

• Stock BaseClientPayload / DeviceProps (no fingerprint overrides, PlatformType UNKNOWN, platform WEB), whatsmeow v0.0.0-20260810134348-a23afe317180 (first report was on a mid-July pin).
• Sends SendPresence(unavailable) once per authenticated stream (the mitigation from discussion #1070), never available.
• Never calls SendMessage, SendChatPresence, or RejectCall, and never responds to any <call> stanza. The only thing that leaves the socket for a <call> node is handleCallEvent's automatic transport <ack>.

It is account-specific, not universal

We log every events.Call* event. Over a recent 7-day window:

• Thousands of 1:1 calls completed normally on the phone while a companion was connected (offer → relaylatency → accept → terminate reason=accepted_elsewhere, median a few seconds). So a passive companion does not universally break calls — which is presumably why this has never been filed.
• For the affected accounts, every call fails until the companion is unlinked.
• The companion has received zero preaccept and zero transport stanzas ever — the peer never attempts media setup with us, and we never claim the call, so this is not "the server thinks the companion answered". The phone's own accept is what the far end sees (its timer runs); media setup after that accept is what dies.
• Zero outgoing-call stanzas ever (every observed call stanza was for an incoming call): companions are not part of outgoing 1:1 call signaling at all. Yet the affected accounts' outgoing calls break too, and unlinking fixes them. So the breakage lever appears to be the companion's registration in the account's device list (capability/identity state the call setup has to satisfy), not anything in the live signaling the companion participates in.

Things whatsmeow doesn't do that a real web client does (possible leads)

1. Real WA Web answers an inbound <offer> with an offer receipt addressed to the caller — <receipt to={caller} id={call stanza id}><offer call-id=… call-creator=…/></receipt> — before (or instead of) any accept/reject, in addition to the transport <ack>. whatsmeow sends only the <ack>. If the caller retransmits/waits on per-device offer receipts during setup, a silent always-online device could stall it. Integrators can't experiment with this today: the parent <call> node's stanza id isn't exposed — BasicCallMeta carries only CallID, and typed events get Data: &child. Exposing the stanza id on BasicCallMeta (set from the parent node's attrs in handleCallEvent) would be a 2-line change that lets downstream users test this without forking.
2. whatsmeow never responds to relaylatency (relay election) — in the same window we saw substantially more relaylatency stanzas than offers, plus terminate reasons relay_bind_failed / setup_failed, so relay setup clearly has per-device components.

Related context: #1159 / discussion #1070 show the server treating a connected companion as the account's active endpoint (push suppression); a comment in #555 reports "Connecting on both devices" when a whatsmeow endpoint participates in a call — consistent with an incomplete endpoint in the call path producing exactly this hang.

Questions

1. Has anyone else seen a passive companion breaking the primary phone's calls since web calling GA? We found no prior report here, in mautrix-whatsapp, or in Baileys.
2. Does anyone know whether current WA Web declares call capability at registration (DeviceProps/payload level), such that a signaling-only companion now silently violates a per-device obligation during call setup?
3. Would you take a PR exposing the <call> stanza id on BasicCallMeta so integrators can experiment with the offer receipt?

Happy to capture more detailed call-signaling traces or try experiments if that would help narrow it down.