fix(ci): make the API-key Seal Twilio + SMS workflow runnable

[izzywdev]

📋 Description

master's seal-sms-secrets.yml adopted Twilio API-key auth (TWILIO_API_KEY_SID / TWILIO_API_KEY_SECRET, preferred over the account Auth Token) — but still pins azure/setup-kubectl to a SHA GitHub can't resolve, so the job dies at "Set up job" before any step runs (Unable to resolve action azure/setup-kubectl@3e0aec4d…). This keeps the API-key model and applies the runnable-infra fix.

Rebased onto current master; supersedes the earlier Auth-Token version of this branch (which would have regressed the auth model).

🔧 What changed (one file: .github/workflows/seal-sms-secrets.yml)

• Drop kubectl + the broken azure/setup-kubectl action. The input Secret manifest is built inline (base64 data:) and piped to kubeseal --merge-into — no action pin to break.
• Fetch the sealed-secrets PUBLIC cert over HTTPS from CERT_URL (same source as deploy/scripts/seal-secret.sh) instead of a cluster fetch — no KUBE_CONFIG / cluster access.
• Commit to master via the RELEASE_BUMP_SSH_KEY deploy key — a bypass actor on the "Protect Master" ruleset, as release.yml's GitOps bump does. A plain GITHUB_TOKEN push 409s.

Seals exactly the secretKeyRefs sms-service.yaml mounts: TWILIO_ACCOUNT_SID, TWILIO_API_KEY_SID, TWILIO_API_KEY_SECRET, TWILIO_VERIFY_SERVICE_SID, and the minted SMS_AUTH_SECRET. Guards unchanged; dry_run previews without committing.

🧪 Testing

• Dry-run dispatched against the branch: it now clears "Set up job" (the fix) and reaches the Require Twilio credentials guard, which fails by design until the four TWILIO_* repo secrets are set. No commit on a dry run.
• Workflow YAML parses; sealed keys match the template's secretKeyRefs exactly.

📝 Notes

• Nothing is sealed or deployed by merging this — it only makes the dispatch workflow correct. Sealing needs the owner to set TWILIO_ACCOUNT_SID / TWILIO_API_KEY_SID / TWILIO_API_KEY_SECRET / TWILIO_VERIFY_SERVICE_SID as repo secrets, then dispatch. sms-service stays enabled: false.
• The same dormant bad pin still sits in seal-consumer-secret.yml (behind an if: skip) — separate cleanup.