fix(whatsapp): scope whatsmeow device per channel instance

[kamushadenes]

Summary

• Resolve each WhatsApp channel's whatsmeow device by JID stored on its channel_instances.config, so multiple WhatsApp instances no longer collide on a shared GetFirstDevice and end up logged in as the same account.
• Persist the paired JID back to channel_instances.config on events.PairSuccess (and on a guarded one-time adoption of a legacy single-device store) so subsequent boots skip QR.
• Add an optional SetInstanceID(uuid.UUID) hook the InstanceLoader calls after construction; the WhatsApp channel uses it to scope its persistence to its own row.
• Reauth() bypasses adoption and clears the cached configJID so a fresh QR pairing always rewrites the JID.

Fixes #1064.

Why this is needed

whatsapp.Channel.Start (and the lazy-init path in StartQRFlow/Reauth) used container.GetFirstDevice(ctx) on a sqlstore.Container that all WhatsApp instances share through the same Postgres DB. With more than one WhatsApp channel_instance, every channel reused the first device row in whatsmeow_device, connected as the same WhatsApp account, and emitted whatsapp QR: start flow failed: GetQRChannel must be called before connecting because the second instance inherited an already-paired Store.ID.

Approach

resolveDevice(ctx) chooses between three paths:

1. config.jid set → container.GetDevice(ctx, jid) reuses that channel's prior pairing.
2. config.jid empty, exactly one device row, exactly one WhatsApp instance, and that instance is us → adopt the device (covers single-instance deploys upgrading to multi-instance without re-pairing the existing account). The adopted JID is persisted immediately so the path collapses to (1) on subsequent starts.
3. Otherwise → container.NewDevice(), which lets whatsmeow.Connect drive a fresh QR pairing. events.PairSuccess writes the new JID back to channel_instances.config.

The adoption guard intentionally refuses to act when the situation is ambiguous (multiple devices or multiple WhatsApp instances) — those configurations require an explicit re-pair.

Migration note

For existing deploys with two+ WhatsApp instances already in the DB but only one device row in whatsmeow_device, set the device JID on the legacy instance's config before deploying, e.g.:

UPDATE channel_instances
SET    config = jsonb_set(coalesce(config, '{}'::jsonb), '{jid}', to_jsonb(<jid>::text)),
       updated_at = now()
WHERE  id = <legacy_instance_id>;

After that, the legacy instance takes path (1) and the second instance takes path (3) on next start. (Single-instance deploys do nothing — they hit path (2) on first boot.)

Test plan

• go build ./... (PG) and go build -tags sqliteonly ./... (Desktop)
• go vet ./internal/channels/whatsapp ./internal/channels ./cmd
• go test ./internal/channels/...
• Deployed to a Postgres-backed gateway with two WhatsApp instances; legacy instance reused its device, new instance got a fresh QR session and bound a separate JID. Restart preserved both pairings.