[alecritson]

For EDW2-215 (Edwardes security audit follow-up, found during the EDW2-201 review).

Why

The contact step (CheckoutController::storeContact) wrote the email to checkout_sessions.customer_email only. It never called the driver's storeContact, which is the one method that touches the cart's address rows.

PR #2 already covered two of the three paths:

• addresses saved after the contact step take the email through withContactEmail();
• completion stamps the placed order through stampContactEmail().

The gap left: rows saved before the contact step stayed empty. A webhook-first Stripe payment creates the order from those rows inside the gateway's authorize(), before completion runs. That order had no customer email unless the host app projected one; Edwardes does this with its own ProjectContactEmail pipeline step.

What

• Controller: storeContact now hands the email to the driver on both the guest and signed-in paths. The signed-in path still associates the customer afterwards.
• Driver: storeContact stamps the email on the existing shipping and billing rows. It creates no rows.
  • It replaces a row's email when that email is empty or is the previous contact-step email, so a corrected email follows through.
  • It keeps an email a row carries of its own, such as a wallet sheet's site contact. This matches the precedence withContactEmail() already uses.
  • The phone, when given, still goes on the shipping row.
• Fingerprint: contact details are already excluded from the driver fingerprint, so stamping rows never bounces a checkout. The gating is unchanged: guests go through ensureWritable, and the driver uses operableCart (409 frozen / 410 gone).
• Email is trimmed before it is stored on the session and the rows.
• Guest side effects. Like every other store verb, the guest contact post now goes through the driver, so it now:
  • resyncs the session, which can invalidate it on a diverged context and dispatches CheckoutSessionResynced;
  • returns 410 when the source cart is gone, where the email used to be saved silently.
• Signed-in path. It recalculates the cart a couple more times per contact post.

Tests

tests/Feature/GuestContactEmailTest:

• the contact email is stamped on rows saved before the contact step;
• an order created straight from the cart (the webhook-first path) carries it on both addresses;
• a corrected email replaces the earlier one;
• a row's own email is kept;
• a signed-in customer's rows are stamped and the customer is still associated;
• a differently cased or padded earlier email counts as the earlier one.

The first five fail against main. ContactInformationTest adds a signed-in frozen-session test: 409, nothing stamped, no association. The full suite passes on SQLite (315). The contact, pay boundary and webhook-first files also pass on MySQL. PHPStan and Pint are clean.

🤖 Generated with Claude Code