feat(alerts): SMS delivery channel

## Problem
Six delivery channels exist (`convex/constants.ts:3-10`): Telegram, Slack,
Discord, email, generic webhook, web push. **No SMS.** Also no Microsoft Teams,
no native mobile push, no voice, no PagerDuty/Opsgenie.

## Why SMS specifically
It is the channel that works when someone is **abroad on a bad connection** —
precisely the duty-of-care scenario. Every incumbent in travel risk has it
because it is the last-resort channel when data fails.

Note also: there is **no native mobile app**. `src-tauri/` is a desktop Tauri v2
build (macOS/Windows/Linux); mobile is a PWA. So an employee gets alerts on a
phone only if they have opened the site in a browser and granted push, or linked
Telegram. There is no app to hand someone. SMS partially closes that gap.

## Considerations
- Provider (Twilio/MessageBird/Vonage), international deliverability, per-message
cost, opt-in and STOP handling, and country-specific regulation
- Cost control matters — SMS is the one channel with real marginal cost, so it
should be entitlement-gated and rate-limited more tightly than the others
- **Phone numbers are PII.** This is the one channel that touches personal data,
which interacts with the deliberately PII-free asset-registry design. Keep
them on the user record, never on a site record.

## Acceptance
- [ ] SMS channel with opt-in and STOP handling
- [ ] Entitlement-gated and separately rate-limited
- [ ] Cost monitoring and a spend cap
- [ ] Phone numbers on the user record only, never on sites

Effort: M (~2d).

Start with convex/constants.ts:3-10 and trace how the existing delivery channels are represented and sent. Review the user-record and entitlement paths before choosing a provider; done means opt-in and STOP handling, tighter rate limits, spend controls, and phone numbers kept off site records.

Written by the indexing model from the issue text.