fix(gateway): recognize whatsapp_cloud as a built-in delivery platform

[hashbender]

What does this PR do?

Adds whatsapp_cloud to the two hand-maintained delivery-platform sets that predate it, fixing silent cron-delivery drops and agent-mode webhook rejections for the WhatsApp Business Cloud adapter.

whatsapp_cloud shipped as a built-in platform (NousResearch#43921/NousResearch#44331): it has a Platform enum entry (gateway/config.py), a working send() (gateway/platforms/whatsapp_cloud.py), and the cron scheduler itself maps it to WHATSAPP_CLOUD_HOME_CHANNEL in _HOME_TARGET_ENV_VARS. But both allow-lists were written before it landed, and the plugin-registry fallback can't rescue it — built-ins never register a PlatformEntry:

1. cron/scheduler.py _KNOWN_DELIVERY_PLATFORMS — a cron job with deliver: whatsapp_cloud runs, saves output locally, and the target silently vanishes in _resolve_delivery_targets (_is_known_delivery_platform → None → no delivery, no delivery_errors entry). The all routing token expands whatsapp_cloud from the home-target map and then drops it at the same gate; cron_delivery_targets() filters it out of the delivery-target picker even when connected. It was the only key in _HOME_TARGET_ENV_VARS absent from the set. Repro:

   # WHATSAPP_CLOUD_HOME_CHANNEL=15551234567
   _resolve_delivery_targets({"deliver": "whatsapp_cloud", "origin": None})  # → []
   _resolve_delivery_targets({"deliver": "telegram", "origin": None})        # → [ok]

2. gateway/platforms/webhook.py _BUILTIN_DELIVER_PLATFORMS — an agent-mode webhook route with deliver: whatsapp_cloud fails "Unknown deliver type: whatsapp_cloud", while the identical config on a deliver_only route works (_direct_deliver calls _deliver_cross_platform without the gate). The asymmetry shows this is drift, not policy.

Downstream delivery is fully generic (Platform(platform_name) lookup → config → live-adapter send), so the two one-word additions are the whole fix. The colon form deliver: whatsapp_cloud:<chat_id> already bypassed the cron gate and worked, making the bare-form silent failure extra confusing.

Same drift family as NousResearch#24987 (yuanbao missing from _HOME_TARGET_ENV_VARS — the other direction). Adjacent, not overlapping: NousResearch#51632 adds write-time deliver validation in cron/jobs.py and would reject whatsapp_cloud at create time for the same root cause; with this fix both layers agree.

Related Issue

None filed; root cause traced to whatsapp_cloud landing after both sets were written (NousResearch#43921/NousResearch#44331).

Type of Change

• Bug fix (non-breaking change which fixes an issue)

Changes Made

• cron/scheduler.py — add "whatsapp_cloud" to _KNOWN_DELIVERY_PLATFORMS.
• gateway/platforms/webhook.py — add "whatsapp_cloud" to _BUILTIN_DELIVER_PLATFORMS.
• tests/cron/test_scheduler.py — deliver: whatsapp_cloud resolves the home-channel target; plus an anti-drift guard asserting every platform in _HOME_TARGET_ENV_VARS passes _is_known_delivery_platform (so the next built-in platform can't silently repeat this).
• tests/gateway/test_webhook_adapter.py — agent-mode send() with deliver: whatsapp_cloud reaches the target adapter instead of "Unknown deliver type".

How to Test

scripts/run_tests.sh tests/cron/test_scheduler.py tests/gateway/test_webhook_adapter.py

All 3 new tests fail on current main and pass with the fix; the full two files are green (278 tests, macOS 15). scripts/check-windows-footguns.py clean on all 4 files.

Checklist

• My code follows the project's style guidelines
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation (N/A — no user-facing docs list the deliver platforms)
• My changes generate no new warnings
• I have added tests that prove my fix is effective
• New and existing unit tests pass locally with my changes

---

Mirror-of: NousResearch#57093
NousResearch#57093