Wire up internal SIP MESSAGE enforcement using a dedicated dialplan context

Confirmed against a live install's pjsip.conf/extensions.conf that every
endpoint falls back to context=intercom for messaging (message_context
blank), and that [intercom] owns one exact-match per-device dial pattern
regenerated on every dialplan rebuild. Rather than risk racing that, every
endpoint now gets message_context=sip-messaging (patched into both of Easy
Asterisk's device-creation code paths, plus a one-time migration for
existing devices), routing messages to their own [sip-messaging] context
gated on the existing pstn-permissions.conf messaging flag.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Ho9mZgAkVpdz7S5wJkg8Nf

docs/pstn-calling-voipms-plan.md

@@ -412,32 +412,34 @@ generator output. Fixed by quoting every value in that heredoc.
     `full`-tier extensions can use it regardless of which countries are
     allowed.
 11. Internal SIP `MESSAGE` (native Asterisk texting, no carrier SMS/cost) —
-    **partially done**. The permission layer is real and live-editable: a
-    `messaging=yes` flag per extension in `pstn-permissions.conf`,
-    independent of the PSTN calling tiers (an extension can be
-    internal-tier for calling and still messaging-enabled, or vice versa),
-    prompted at install time AND now a checkbox right in the Security
-    Dashboard's PSTN Trunk permissions table (alongside tier/approved-
-    numbers) — no need to re-run the CLI installer just to change who can
-    message. Confirmed it correctly survives tier changes and personal-DID
-    assignment/removal on the same extension (this is what surfaced the
-    tier=internal section-wipe bug fixed above). **Not done**: the actual
-    dialplan wiring that would make Asterisk *enforce* this flag on
-    inbound `MESSAGE` requests — this flag currently does nothing at the
-    Asterisk level yet, it's groundwork.
-    Reasoned through but deliberately not shipped: Easy Asterisk dispatches
-    messages through the same `[intercom]` context calls use (no
-    `message_context` override), and whether a hand-written pattern there
-    would take precedence over — or conflict with — Easy Asterisk's own
-    generated per-device dial patterns in that same context isn't something
-    that can be safely determined without a live install to test against.
-    Shipping a guessed pattern risked either silently not working or, worse,
-    interfering with call-routing precedence for the same extensions.
-    Treat this the same way as the VoIP.ms live-account verification in
-    item 6 above: a real gap, flagged rather than papered over, not a
-    hypothetical. Next step for whoever picks this up: verify message
-    routing behavior against a live Easy Asterisk container, then wire the
-    dialplan gate using the existing flag.
+    **done**. The permission layer: a `messaging=yes` flag per extension in
+    `pstn-permissions.conf`, independent of the PSTN calling tiers (an
+    extension can be internal-tier for calling and still messaging-enabled,
+    or vice versa), prompted at install time AND a checkbox right in the
+    Security Dashboard's PSTN Trunk permissions table (alongside
+    tier/approved-numbers) — no need to re-run the CLI installer just to
+    change who can message. Confirmed it correctly survives tier changes and
+    personal-DID assignment/removal on the same extension (this is what
+    surfaced the tier=internal section-wipe bug fixed above).
+    The dialplan gap flagged here previously is now closed: a real install's
+    `pjsip.conf`/`extensions.conf` were pulled (2026-07-23) and confirmed
+    every endpoint sets `context=intercom` with `message_context` blank
+    (falls back to `context`), and `[intercom]` gets one exact-match
+    `exten => <ext>,1,...` per device, freshly regenerated by Easy
+    Asterisk's own `rebuild_dialplan()` on every dialplan rebuild — exactly
+    the collision this doc worried about. Solved by NOT sharing
+    `[intercom]`: `services/asterisk-digital-ocean.sh` now explicitly sets
+    `message_context=sip-messaging` on every endpoint (patched into both of
+    Easy Asterisk's device-creation code paths — the CLI menu's bash
+    heredoc and the web admin's Python `add_device()` — so new devices pick
+    it up automatically, plus a one-time migration for devices that already
+    existed) and routes messages to a dedicated `[sip-messaging]` context in
+    `messaging-dialplan.conf`, gated on the sender's `messaging` flag via
+    `AST_CONFIG()`. Zero overlap with `[intercom]`'s own call routing.
+    One piece still flagged rather than papered over: the `MESSAGE(from)`
+    sender-extraction (`CUT()`-based, written to tolerate a display-name
+    prefix) hasn't been confirmed against real MESSAGE traffic yet — fails
+    closed (denies) if it ever parses wrong, but worth a live test.
 12. Anveo Direct's real-time \$0-balance blocking, confirmed — support reply
     (MFonk, 7/22/2026): "all calls (incoming and outgoing) will be blocked"
     at \$0, in real time, not just via a recurring-fee grace period. This