Insights: remove the BIMI readiness check

[heliocosta-dev]

Removes the bimi_ready deliverability check. It was info-only (weight 0), but it failed on every email from a domain that published the DMARC record our own setup recommends (p=none), so even a 10.0 report showed a cross under Improvements. Its advice ended in a paid mark certificate for Gmail (about US$800–1,750 a year per domain), and a logo doesn't change where mail lands.

Change

• Engine (packages/core/src/email-insights.ts): the check leaves CHECKS and the evaluator. CHECK_IDS is exported.

• Stored reports: email_insights rows are never rewritten, so readers keep only checks the catalog still has:

  • fetchEmailInsights / fetchBroadcastInsights, behind the email and broadcast pages and GET /emails/{id}/insights;
  • fetchContentFactors, behind Metrics score details and the console safety page (c->>'id' in (...), the catalog ids as parameters).

  Without this, older emails would keep the cross, or render a missing translation key once the copy is gone.

• SCORE_VERSION stays 1. The check weighed 0, so no score changes. The docs now say a zero-weight check can be added or retired without a version bump, and that a retired check disappears from older reports.

• Copy: the check's en and pt-BR strings are gone, and the DMARC record description no longer says enforcement "unlocks BIMI". The docs table rows are removed in both languages.

API

Reports from GET /emails/{id}/insights, old and new, no longer include bimi_ready. The SDKs type check ids as an open set, so nothing breaks at compile time; a consumer that looked the id up by name now finds nothing.

Verification

• pnpm lint (the same 8 warnings as main), pnpm typecheck, and pnpm test: 2,992 tests across 11 packages.
• New tests: both lookup paths drop a stored bimi_ready, and the factors query skips it, while a failing zero-weight info check that is still in the catalog (images_offsite) stays in both. The factors fixtures now use real catalog ids instead of made-up ones.
• An adversarial review covered every reader of stored checks, the API contract, docs, i18n parity and the sibling SDK repos. Its one finding, that the tests couldn't tell the catalog filter apart from a severity or weight filter, is fixed by the images_offsite fixtures above.

🤖 Generated with Claude Code