#2016 feat(nurture): arm the first flow — extension published, email only, verified in prod

Parent: the product-nurture epic. The first real send.

Problem

Everything up to here has been verified without contacting a single operative. This issue turns the machine on, once, on the safest possible flow, and proves the whole spine end to end in production.

Why this flow first

extension_published (whiteboard #4, GROW CHAMPION) is the right first arm for four independent reasons:

1. Event-triggered, not time-triggered. It fires off extension_published, which the app already emits. There is no dormancy window to get wrong.
2. The cold-start backlog is bounded and inspectable — the set of already-published extensions, which you can count before arming.
3. It cannot be wrong in a way that hurts. The worst failure is congratulating someone who did publish an extension.
4. Its occurrenceKey is the extension name, so it exercises the repeatable case rather than the trivial once-ever one — which is the part of the dedupe design most worth proving early.

What ships

• Arm extension_published, email channel only. The inbox comes in D1; keeping this to one channel means a failure here has one possible cause.
• The cold-start seal runs first and claims every historical publish. Record the sealed count on this issue before flipping the arm.
• A per-tick send cap (propose 10) for the first week.

Verification — in production, not just in tests

1. Confirm the sealed count matches the count of pre-armedAt published extensions, from a hand-run query. If they differ, stop.
2. Publish a real extension from a test account. Confirm exactly one row moves candidate → sent, the email arrives, and the panel shows the provider message id.
3. Publish a second extension from the same account. Confirm a second row is created (the occurrence key is the extension) and a second mail arrives.
4. Re-publish a new version of the first extension. Confirm no new row — the key is the extension, not the version.
5. Run the projector twice in the same window. Confirm zero duplicate sends.
6. Unsubscribe from the footer link, publish again, confirm the row is suppressed with the reason rendered and no mail is sent.

Steps 3–6 are the ones that actually prove the epic's central claim. Do not skip them because step 2 passed.

Out of scope

Every other flow. Do not arm a second flow in this issue — the whole point is that a failure here has exactly one candidate cause.