fix(sdk): drop Message.blockedReason — abuse block reason is operator-only

[tuyakhov]

Sync pass over senderkit-app main covering everything merged since the last run (the blocked-status sync, app PR #196). Reviewed app PRs #198–#211.

Outcome

Only one app change affects the SDK/CLI/MCP surface — and it's a correction to the previous sync, not a new feature.

Message.blockedReason is operator-only → removed from the SDK

App #211 ("keep spam-detection detail out of customer-visible surfaces") makes the data model explicit:

• The customer-facing message read column set (messageColumns, backing GET /v1/messages list & get, the SSE tail, and the logs SSR fetch) deliberately omits blockedReason. Git history confirms the column was never in that set — the only commit to touch it in lib/services/messages.ts is #211, and only to add the exclusion.
• A blocked send writes the detailed reason to the operator-only blockedReason column + the admin abuse review. The customer sees only a generic blocked entry on the message timeline (app's PUBLIC_BLOCK_REASON = "Blocked by automated content safety checks.").

The prior sync added an optional Message.blockedReason field and documented "the trigger is on the message's blockedReason". Since the public API never returns it, that field would never be populated. This PR:

• Removes Message.blockedReason from packages/sdk/src/types.ts.
• Corrects the Message.status doc (types.ts) and the MESSAGE_STATUSES doc (mcp-schemas.ts) to state the trigger is operator-only and customers see only a generic blocked timeline entry.
• Adds a changeset (@senderkit/sdk + @senderkit/cli, patch).

The blocked status itself, MESSAGE_STATUSES, and the senderkit_messages_list status filter are unchanged.

No SDK action needed (reviewed, internal-only)

App PRs	Area	Why no SDK impact
#198, #202, #203, #205–#208, #211	Abuse pipeline internals — shared email/SMS scan orchestration, LLM classifier dedupe, block-threshold tuning, loopback/private-IP link allowlisting, operator-alert de-dupe + HTML escaping	Worker/heuristics internals. No change to the public API request/response contract; the blocked status was already synced.
#209, and admin UI in #211	Admin abuse review page (scrollable list, admin email preview) + new messages.renderedVersion column powering it	Operator-only UI/DB. renderedVersion is not in the customer column set, so not exposed by the API.
#210, #201	Supabase integration — marketing/integration page, partner-listing doc, and a spec + plan for future agent-driven Supabase wiring	Docs + a marketing page and step mocks. No SenderKit MCP tools, CLI commands, or SDK methods added.
#199, #200	Account/impersonation card tweaks, onboarding checklist, transactional email copy, table UI	Internal app UI; no API surface.
—	lib/messages/cursor.ts extraction (base64url cursor codec)	Pure refactor; cursor wire format unchanged, so existing cursor/nextCursor SDK handling is unaffected.

Verification

• pnpm --filter @senderkit/sdk build ✅
• pnpm --filter @senderkit/sdk test ✅ (58 passing)

🤖 Generated with Claude Code

https://claude.ai/code/session_01ACZUdzMZGZFNjwfSZ42E2u

---

Generated by Claude Code