feat: add WhatsApp quote and status primitives

[aldoeliacim]

What does this PR do?

Adds WhatsApp quote/reaction/status primitives that Baileys supports natively but Hermes was paving over with plain-text follow-ups.

• Adds a bounded WhatsApp bridge WAMessage cache so Baileys can send native quoted replies instead of plain-text follow-ups.
• Propagates incoming quote metadata (quotedMessageId, quotedText, quotedRemoteJid) into Hermes MessageEvent reply context.
• Wires media replies through /send-media and adds bridge primitives for message reactions, private status replies, status reactions, and explicit-recipient text status posts.
• Keeps status ingestion disabled by default; statuses are only admitted when platforms.whatsapp.extra.statuses.enabled: true and ingest: true.
• Adds whatsapp_action, a WhatsApp-specific messaging tool for owner/user-requested advanced actions: react_message, status_reply, status_react, and post_text_status.
• Adds Node bridge tests and Python tool/adapter tests.

Design notes

• The advanced status/reaction primitives live behind bridge/adapter methods and a WhatsApp-specific tool rather than broadening generic send_message; this keeps WhatsApp-specific semantics explicit.
• whatsapp_action includes dry_run=true so agents can inspect the exact bridge endpoint/payload before performing external side effects.
• Status posting requires a non-empty explicit status_jid_list; there is intentionally no "all contacts" fallback.
• Native quotes degrade gracefully: if replyTo is not in the bridge cache, the bridge sends the message without a quote and reports quoted: false.
• Bridge imports are now side-effect-light so node:test can import helper functions without starting an HTTP server or socket.

Operational follow-up after merge

• Real-device smoke test for status replies/reactions; Baileys status support is known to be flaky upstream and should be validated against an actual WhatsApp session before enabling any automation.

Related Issue

No related issue — surfaced from production WhatsApp use where plain-text "@reply" fallbacks felt wrong vs the platform's native quote/reaction UX.

Fixes #

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• scripts/whatsapp-bridge/bridge.js — WAMessage cache; new /send-media-reply, /react, /status-reply, /status-react, /post-text-status endpoints; side-effect-light import surface for tests.
• scripts/whatsapp-bridge/bridge.test.mjs — Node test suite for the new primitives.
• gateway/platforms/whatsapp.py — quote metadata propagation; adapter methods for reactions/status/replies.
• tools/whatsapp_action_tool.py — new whatsapp_action tool: react_message, status_reply, status_react, post_text_status, with dry_run.
• tests/tools/test_whatsapp_action_tool.py, tests/gateway/test_whatsapp_*.py — coverage for tool + adapter wiring.

How to Test

1. ./venv/bin/python -m pytest tests/tools/test_whatsapp_action_tool.py tests/gateway/test_whatsapp_*.py tests/gateway/test_platform_base.py -q
   — 188 passing on current rebase.
2. cd scripts/whatsapp-bridge && npm test -- --test-reporter=spec for the Node bridge primitives.
3. node --check scripts/whatsapp-bridge/bridge.js and ./venv/bin/python -m py_compile tools/whatsapp_action_tool.py gateway/platforms/whatsapp.py for syntax sanity.
4. Real-device smoke test (post-merge): use the whatsapp_action tool with dry_run=true first to inspect the bridge payload, then run with dry_run=false against a paired WhatsApp session.

Checklist

• Tests added/updated and passing locally (188 pass)
• Rebased on origin/main (2026-05-25; one trivial conflict in whatsapp.py was an additive merge — kept upstream's new pre-flight pairing check plus this PR's bridge-found log line)
• Follows existing code conventions for gateway/platforms/* adapters and tools/* modules
• Documentation updated where needed (design notes inline + tool docstrings)
• Conventional commit messages

Notes for reviewers

• The breaking-change risk is contained to the WhatsApp surface; whatsapp_action is a new tool, whatsapp.py additions are backward compatible (existing callers see the same methods plus new optional ones).
• Status ingest stays off by default. The opt-in lives behind two flags (enabled + ingest) precisely because Baileys status support is fragile and shouldn't fail-open into surprise behavior.

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[austinpickett]

Please fix merge conflicts and use .github/PULL_REQUEST_TEMPLATE.md

[aldoeliacim]

@austinpickett both points from your review should be addressed now:

1. Merge conflicts — resolved. The branch is freshly rebased onto current origin/main (force-pushed above) and now merges cleanly with zero conflicts. Locally tested: 60 passed across the WhatsApp formatting/gating/action-tool suites.
2. PR template — the description already follows .github/PULL_REQUEST_TEMPLATE.md (What/Related Issue/Type/Changes Made/How to Test/Checklist sections are all filled in).

Would appreciate a re-review when you have a moment. Thanks!

[aldoeliacim]

Acknowledged — this branch has drifted into a multi-commit stack that overlaps several other open PRs and needs a clean rescope onto current origin/main (rebuilding with only the net-new WhatsApp quote/status/reaction primitives, dropping the commits that have since landed or that belong to sibling PRs). The straight rebase hits a design conflict in gateway/platforms/base.py / whatsapp_common.py where upstream refactored the functions this PR edits in place.

I'm handling that rescope as its own focused pass rather than force a hand-resolution here, and will re-push against the PR template once it's a single coherent commit. Leaving the branch as-is in the meantime so no half-resolved state lands.

[aldoeliacim]

Heads-up for reviewers: the reaction portion of this PR (the bounded TTL'd messageStore + /react endpoint + unified adapter contract) has been split out and reconciled into #50670 (stacked on #50661), which is green and reviewable as a focused unit. This PR's remaining unique surface is the status primitives (status-reply / status-react / post-status) and quote threading. It still predates the platform-plugin migration (#41112) and needs a refresh onto current main; I'll rebase the status-only scope separately.