Correct two docs left describing SMS as ntfy push, not AMI delivery

services/sms-inbound.sh was rebuilt to deliver texts into Asterisk over AMI,
landing in the softphone's own thread, and ntfy was dropped from that path
entirely. Two pieces of prose written against the earlier design survived and
now contradict the working implementation:

- docs/anveo-direct-setup-guide.md still ended its "native Messages app"
  section with "Codes arrive as ntfy push notifications instead". The point
  of that section — no SIP client can write into Android Messages or iOS
  Messages — is unchanged, but the place texts actually land is Sipnetic's
  message thread.
- services/pstn-trunk.sh's generated README claimed inbound SMS "doesn't
  touch Asterisk at all" and set up ntfy notifications. It is now the exact
  opposite: sms-inbound reads this service's pstn-personal-dids.conf and
  pstn-groups.conf to resolve DID ownership, the same files the inbound-voice
  ring logic uses, which also makes install order matter — noted there now.

Documentation only; no behaviour change, and services/sms-inbound.sh is not
touched.

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

docs/anveo-direct-setup-guide.md

@@ -297,9 +297,10 @@ them.
 
 Android's Messages app reads the telephony SMS provider, which only the
 cellular radio (or whichever app holds the default-SMS-app role) writes to;
-iOS lets nothing write to Messages at all. Codes arrive as ntfy push
-notifications instead — which, for a passcode you're about to read and type,
-is the more useful place anyway.
+iOS lets nothing write to Messages at all. No SIP client can inject into
+either, so texts to this number arrive in **Sipnetic's own message thread**
+(or whichever softphone is registered to the owning extension) and nowhere
+else. That's a platform limit, not something the delivery path chooses.
 
 ## Provider risk and keeping the number