REST: WhatsApp resources (businesses/numbers/templates) missing from the SDK

[briankwest]

Summary

The entire WhatsApp surface of the Message API is defined in the spec but absent
from the SDK — zero references anywhere in the tree. Native SMS/MMS messaging is
wired (client.messages.create / .update), but the WhatsApp businesses,
numbers, and templates resources that sit alongside it under /api/messaging
have no accessor.

Spec

specs/signalwire-rest/message-api/whatsapp-{businesses,numbers,templates}/main.tsp

operationId	method + route
list_whatsapp_businesses	GET /api/messaging/whatsapp/businesses
list_whatsapp_numbers	GET /api/messaging/whatsapp/numbers
retrieve_whatsapp_number	GET /api/messaging/whatsapp/numbers/{id}
list_whatsapp_templates	GET /api/messaging/whatsapp/templates
retrieve_whatsapp_template	GET /api/messaging/whatsapp/templates/{id}
create_whatsapp_template	POST /api/messaging/whatsapp/templates
update_whatsapp_template	PATCH /api/messaging/whatsapp/templates/{id}
delete_whatsapp_template	DELETE /api/messaging/whatsapp/templates/{id}

These are the counterpart to the WhatsApp send path that client.messages.create
already supports: create_message accepts a whatsapp:-prefixed from plus a
template_id, but there is no way through the SDK to list the WhatsApp numbers
you can send from or to manage the templates you reference. So the send call is
wired while its prerequisites are not.

Current SDK state

Verified against signalwire-python@main:

$ grep -rniE "whatsapp" signalwire/ | wc -l
0

No whatsapp_businesses / whatsapp_numbers / whatsapp_templates resource,
no accessor on any namespace, nothing in the generated files. It is not merely
unwired (like dialogflow) — it is entirely absent from codegen.

Proposed shape

Three resources under a client.messaging (or client.whatsapp) namespace, to
sit beside the existing native client.messages:

client.whatsapp.businesses.list()
client.whatsapp.numbers.list()
client.whatsapp.numbers.get(id)
client.whatsapp.templates.list()
client.whatsapp.templates.get(id)
client.whatsapp.templates.create(...)   # POST
client.whatsapp.templates.update(id, ...) # PATCH
client.whatsapp.templates.delete(id)

Businesses and numbers are read-only per the spec; templates are full CRUD
(create/update/delete plus the two reads).

Coverage note

Not in REST_COVERAGE_GAPS.md. If WhatsApp is intentionally deferred, an
explicit sdk-gap block for these eight operations would document the decision;
otherwise this is net-new resource wiring.

Why it matters / downstream

swsh (SignalWire CLI + TUI) wants to present WhatsApp as a first-class channel:
pick a whatsapp: sender from the numbers list, choose an approved template,
send. Without these three resources swsh can send a WhatsApp message but cannot
discover what it is allowed to send or manage the templates it must reference, so
it falls back to raw HTTP for the whole surface.