R6.3 Campaign parity for AISL

Plan issue R6.3 (community-base plan phase 6, docs/plan/phase-6.md). Depends on R1.5 (done, #19).

Goal: bring Relay campaign management to parity with what AISL runs today, so the phase 6 cutover (A6.x) can move campaigns, contacts and preferences onto Relay without losing studio capability.

Scope:

• Audience filters by tag set, category subscription and a client-provided recipient list (the recipient-lists API already exists).
• Recount endpoint for a filtered audience.
• Campaign detail with per-recipient disposition as AISL shows today.
• Retry a failed delivery; assume sent operator action.
• Tags sync: AISL pushes tier:<slug>, newsletter, and Studio user tags as contact tags on change (subscription.changed callback closes the loop). The AISL-side push lands with A6.2; Relay accepts and stores contact tags in this issue.

Non-goals:

• No SES sending changes beyond disposition recording.
• No tenant provisioning changes (R6.1 owns production tenancy).

Verification:

• Sandbox: create a campaign for tag tier:main with 3 contacts -> recount 3 -> send -> 3 recipient rows with dispositions.

Read first:

• ~/git/ai-shipping-labs/email_app/services/campaign_audience.py, campaign_recipients.py, studio/views/campaigns.py, specs/10-email.md.

Start with docs/plan/phase-6.md, then read services/campaign_audience.py, campaign_recipients.py, studio/views/campaigns.py, and specs/10-email.md. Trace the existing recipient-lists API and campaign flow before addressing filters, recounting, dispositions, retries, operator actions, and contact-tag storage. Done when the sandbox scenario creates a tag-filtered campaign for three contacts, recounts three, and records three recipient dispositions.