feat(admin): onboarding checklist and a status screen that reports only stored state

[TheAggressive]

Closes #154. Part of #65.

What changes

Onboarding checklist (Campaigns screen)

• There are five steps: connect and verify Mailchimp, choose a default audience, set up the Brand Kit, publish a template, and create a first campaign.
• Onboarding_Checklist re-derives every step from stored state on each read. If a prerequisite is removed, its step reopens. That includes trashing the last published template or losing verification.
• The Mailchimp steps are optional, because HTML export needs no provider.
• GET /campaignbridge/v1/onboarding returns the checklist. POST /onboarding/dismiss hides it for the current user (stored in prefixed user meta through Onboarding_Dismissal_Repository), and only once the required steps are done. Before that it returns 409 campaignbridge_onboarding_incomplete. Both routes require campaign access.
• A "Set up" link is offered only to users with the capability for that step. The campaign step opens the existing New campaign dialog.

Status screen

• Removed the placeholder integrations data: a hardcoded 1.0.0 version, and class_exists() reported as "active". Also removed the unrelated site counts (users, posts, pages).
• New CampaignBridge Health section:
  • schema currency;
  • Mailchimp connection, plus when it was last checked;
  • default audience;
  • published templates;
  • campaign counts by state, from the new Campaign_Repository::state_counts() (GROUP BY state).
• A warning links to Campaigns when any campaign needs reconciliation.

Mailchimp verification is now recorded

• Bug found while building this: the Providers tab already pinged Mailchimp, but threw the answer away. Nothing called with_verification(), so is_verified() was always false.
• The check now records a definite answer on the stored connection: success, or Mailchimp refusing the key (401/403).
• It writes only while the same encrypted key is still stored. A timeout or network failure proves nothing, so the previous state stands.

Evidence (#154)

• Browser E2E (tests/e2e/onboarding.spec.ts): a brand-new administrator sees the open checklist, and its rendered state is checked step by step against GET /onboarding. The spec runs axe on the checklist, creates a campaign from the checklist, sees "You're set up", dismisses it, and the checklist stays hidden after reload. When no other published template exists (CI), it also checks that the checklist comes back once the template is deleted.

• Integration (Onboarding_Checklist_Test): each step follows its stored source:

  • an unverified connection or empty audience leaves the step open;
  • the Brand Kit defaults versus a custom kit;
  • a draft versus a published template;
  • the per-owner campaign count.

  It also covers: the optional Mailchimp steps; the 409 on early dismissal; the checklist reappearing after a step is undone; per-user dismissal; 403 for users without access; capability-gated links; Status counts derived from stored campaigns; and an audit that Status has no fixed version or mock figure.

• Integration (Provider_Verification_Test): a 200 ping records verified (and keeps the audience); a 401 records unverified; a timeout keeps the previous state; a cached check makes no second request.

Verification

• pnpm qa:fast, plus the unit (1126), integration (428), security (117), accessibility (25), and performance suites: all pass.
• pnpm build passes.
• E2E against Studio passes for onboarding, campaigns, and accessibility.

Notes

• On an existing site, Status will show the connection as "Not checked yet" until someone opens Settings → Providers once.
• The Status grid's styling is unchanged. Its stylesheet targets .cb-status, not the screen's campaignbridge-status classes; that predates this PR.

🤖 Generated with Claude Code