fix(baileys): fold neutral @c.us participant ids to engine dialect for group ops

[rmyndharis]

What

The engine boundary uses a neutral JID dialect (<phone>@c.us, <id>@g.us, <lid>@lid). The Baileys group-participant operations — addParticipants / removeParticipants / promoteParticipants / demoteParticipants and createGroup — passed the caller-supplied participant ids straight to groupParticipantsUpdate / groupCreate. A neutral <phone>@c.us id is then placed raw on the binary wire as an unknown c.us server suffix, instead of the single-byte s.whatsapp.net protocol token. This broke the engine's neutral-id round-trip invariant for group ops.

(1:1 messaging is unaffected — Baileys' relayMessage re-derives the destination from the decoded user part.)

Change

Fold participant ids back to the engine dialect via the existing toEngineJid transform (now reused at the adapter boundary through a small toEngineParticipants helper) before the group calls. @lid (a first-class addressing mode) and the @g.us group id are left untouched.

Preserved behaviour

• A @s.whatsapp.net participant id (the previous shape) is idempotent through the transform.
• getGroupInfo / getGroups still return neutral @c.us participant ids — the displayed ids are re-canonicalized from Baileys' response metadata, independent of the outbound wire dialect.
• The whatsapp-web.js engine is deliberately untouched (@c.us is its correct native dialect).

Tests

New baileys.adapter.spec.ts cases assert that @c.us participants reach the socket as @s.whatsapp.net across all four ops and createGroup, while @lid passes through unchanged. Backend lint + build + full jest green.