docs: record native Stripe mailing-list opt-out verification

Author: richiemcilroy

emails/QA.md

@@ -53,7 +53,9 @@ The native Stripe integration is connected to Cap Software, Inc. and enabled for
 
 The independent GitHub delivery check is implemented but not deployed or enabled. Its local tests cover healthy operation, stale/unavailable health, manual hold, persistent holds after recovery, guarded manual resume, audience drift and partial provider failure. A real Loops API test applied the hold to all four production drafts, read back the downstream filters, and confirmed simulated recovery left them held. This sent no emails. It proves the API mutations on drafts, not the behavior of an already-running journey during a deployed outage. GitHub delays and a Loops API outage can delay or prevent the hold; scheduled campaigns remain a separate manual preflight and cancellation responsibility.
 
-The deployed Cap signup/purchase/invite path has not yet been proven end to end. Production schema/code deployment, recipient Preference Center list-opt-out preservation across native Stripe updates, the final Bento suppression delta, and scheduler monitoring remain cutover gates. The Cap-worker API list-removal check above does not independently prove native Stripe handling of a recipient list opt-out. The worker retries failed updates, but Loops still uses the last successfully synced values during an outage; `capVerifiedAt` is not a native expiry rule.
+A separate recipient Preference Center test used an existing delivered QA message. The owned contact was globally subscribed with the Product updates and tips list selected, then the recipient switched that list off while leaving global subscription on. Updating the owned Stripe fixture delivered the new name to the same Loops contact and preserved its absent list membership. No new email, payment or subscription was created. The contact was held throughout and globally unsubscribed again afterward.
+
+The deployed Cap signup/purchase/invite path has not yet been proven end to end. Production schema/code deployment, the final Bento suppression delta, and deployed scheduler monitoring remain cutover gates. The worker retries failed updates, but Loops still uses the last successfully synced values during an outage; `capVerifiedAt` is not a native expiry rule.
 
 Follow the [cutover runbook](../scripts/loops/README.md#before-any-activation). Test that deployed path using owned inboxes, including outages and retries, before requesting production activation. Keep imported history held, preserve all opt-outs, reconcile fresh Bento changes, check Resend overlap and disable duplicate Bento automation only during the approved cutover.
 

scripts/loops/README.md

@@ -123,7 +123,7 @@ The existing photo was visibly confirmed beside `Richie from Cap <richie@mail.ca
 Activation is deliberately outside this migration's approved scope. These gates remain necessary:
 
 1. Review the final custom drafts and audiences, and configure rotated credentials in the intended environment. September 11 controlled deliveries passed SPF, DKIM and DMARC with inherited `p=quarantine`; the earlier DMARC warning is no longer an observed blocker. Recheck sending-domain status at cutover.
-2. The native Stripe connection passed an owned live-customer creation/update test, including name sync, list assignment and global unsubscribe preservation. Independently test a recipient Preference Center list opt-out across a Stripe update; the separate Cap-worker API list-removal check is not proof of that native behavior. Import/reconcile the remaining Bento negative records with workflows off. Then deploy the reviewed schema/code in test mode and prove the actual signup, purchase and invite routes with owned accounts.
+2. The native Stripe connection passed owned live-customer creation/update tests, including name sync, list assignment, global unsubscribe preservation and a recipient Preference Center mailing-list opt-out surviving a later native update. Import/reconcile the remaining Bento negative records with workflows off. Then deploy the reviewed schema/code in test mode and prove the actual signup, purchase and invite routes with owned accounts.
 3. Set the explicit cutover timestamp, verify the cron schedule and permissions in the deployed environment, and seed the completed-account sync jobs. Keep enrollment disabled while inspecting the resulting contacts. Preserve existing opt-outs and suppressions; no separate consent-capture step is needed.
 4. Configure and enable the independent delivery check above, verify its deployed health endpoint and failure notifications, and prove purchase/invite/opt-out transitions remove contacts before later promotional steps. Exercise its hold and explicit recovery with an owned-account journey. Downstream filters use the last synced fields; `capVerifiedAt` is not a native expiry guarantee. Pause workflows manually if the checker cannot reach Loops, and handle scheduled campaigns separately.
 5. Reconcile a fresh Bento delta at cutover, including all opt-outs and changed entitlements. Confirm no campaign/flow is queued to send twice, check overlap with Resend recording emails, then disable old Bento marketing automations only as part of the approved cutover. Preserve source history and suppression evidence.