fix(engine): pass the destination chat to whatsapp-web.js link-preview generation

[rmyndharis]

Closes #1006.

The defect

A YouTube URL posted to a WhatsApp Channel arrives with a blurred or empty preview thumbnail. The
same URL in a normal 1-on-1 chat renders correctly — the reporter's own A/B in #1006 established that,
and it is what makes the failure specific rather than a platform-wide compression artefact.

WhatsApp Web selects a different preview transport for newsletters. whatsapp-web.js 1.34.7 calls the
internal action with the chat omitted:

let preview = await window.require('WAWebLinkPreviewChatAction').getLinkPreview(link);

so the action cannot select that transport, even though the message is afterwards handed to
sendNewsletterMessageJob. The preview is generated as if for a normal chat and then sent down the
newsletter path.

Why the second argument is real

Read off the live WhatsApp Web build inside a running session rather than inferred from docs:

{ "arity": 2, "source": "function k(e,t){return I.apply(this,arguments)}" }

getLinkPreview declares two parameters. Passing the chat fills a parameter the function actually
has — this is not an extra argument being harmlessly ignored, and it is not one being repurposed.

The change

The same shape as the existing 201832 backport: an exact source transform applied to the installed
dependency, plus a spec that asserts the installed tree carries it.

The transform is deliberately narrow and refuses to guess:

Installed shape	Result
exactly one legacy call	patched
already carries the chat	skipped, unchanged
neither shape present	throws, unchanged
both shapes present	throws, unchanged

postinstall runs it with --best-effort, so a local install never hard-fails. The production Docker
stage runs it strictly after npm ci, so dependency drift becomes a build failure rather than an
image that silently ships without the fix. The two runs compose correctly: postinstall applies it,
the strict run then skips; if the shape is unknown, postinstall warns and the strict run fails the
build.

scripts/check-dockerignore.mjs gains the new script as a must-keep path, so it cannot be excluded
from the build context without failing the guard.

Scope

The edit path (sendMessageEdit) is deliberately untouched. It is a separate call site with a
different binding, and editing a link message on a channel is not the reported symptom — a channel
edit still uses the old preview path.

Verification

• npm run test:scripts — 17/17, covering all four transform branches against temporary fixtures
• full Jest suite — 252 suites / 4051 tests, including the new adapter spec that asserts the installed
  dependency carries the patched call
• npm run lint, tsc --noEmit, node scripts/check-dockerignore.mjs — clean
• the arity reading above was taken from a live authenticated session, not from documentation