Harden Direct delivery lifecycle and cost-safe monitoring

[Web-pixel-creator]

Summary

• harden Telegram Direct primary-result delivery semantics for confirmed, definitive-retryable, definitive-terminal, and ambiguous outcomes
• use a two-phase session claim/commit so an undelivered result cannot leave phantom lastCheck context
• keep scheduled production monitoring free of AI-provider calls by default; expose a separate exact manual opt-in probe
• correct the cross-brand official-domain property oracle and normalize migration fixture line endings on Windows
• reconcile release, canary, recovery, and on-call documentation with the implemented contract

Verification completed locally

• Vitest: 167 files, 12,890/12,890 tests
• coverage: 85.82% statements, 80.52% branches, 91.33% functions, 87.75% lines
• TypeScript, production build, Prettier, actionlint, and ESLint (0 errors; 8 pre-existing Fast Refresh warnings)
• Supabase: 33 migrations, schema lint clean, pgTAP 92/92
• release container health smoke passed
• Trivy: 0 fixable High/Critical findings
• Bun audit: no vulnerabilities
• current diff Gitleaks scan: no leaks

No real Telegram messages, AI-provider requests, Railway changes, Supabase cloud mutations, merge, or deployment were performed for this candidate.

Explicit boundaries

• Telegram does not provide an idempotency key; strict exactly-once delivery still requires a durable outbound journal/outbox.
• result reuse across restart/instances remains an optional future durable-cache improvement.
• the two-phase correction is scoped to the primary Direct check result; the separate OCR fallback pre-save/rollback path remains a documented P2.
• the default scheduled monitor must remain AI-free; the manual AI probe requires separate budget approval.

Release gate

This PR is intentionally unmerged. Merge and Railway deployment require separate approval. The documented invalid Railway us-west2 region must also be corrected before a deployment attempt.