test(e2e): fix four CI flakes at root cause and make the Stripe block… - #3360

…-checkout failure diagnosable

The nightly develop e2e run has been red since 2026-07-31. Four of the failures are
test-side defects and are fixed here; the thirteen stripe-express ones are NOT fixed,
because their cause is still unproven and papering over them would hide a real signal.

Every fix below is a race/wait/selector fix. No assertion was weakened and no test was
skipped.

Four flakes, all the same shape — a one-shot read of a React surface taken before it
settles, then compared against a later value:

* customer: addDefaultProductToCartAndAssert raced
  `Promise.all([waitForLoadState('load'), click()])`. A click that triggers navigation
  already auto-waits for scheduled navigations, so pairing it with a second load wait
  made the click itself time out at 30s under CI load. Click, then assert arrival
  web-first. Both navigation sites in the method.

* abuse-reports: waitForListReady() returns on the first render that has any rows, which
  is not the final render. The TC10 baseline captured a transient 20 rows that
  re-rendered to the real 2. Adds getStableRowCount() (same count twice running) and a
  web-first expectRowCount().

* vendor-auction / request-for-quotes / vendor-support: parseTabCount cannot distinguish
  a genuine "(0)" from a tab whose count has not rendered yet, because DataViews paints
  "All" before "All (3)". Adds expectTabCountAtLeast() to utils/dataViews.ts and applies
  it to the three specs with that shape. Expected-zero assertions deliberately keep the
  plain read — polling for zero would just burn the timeout.

* vendor-reports: reports/helper.ts::shouldBlockNavigation() redirects report paths via
  document.location.href. When that beats DOMContentLoaded the browser cancels the
  original navigation and goto() rejects with net::ERR_ABORTED even though the page loads
  fine. Adds gotoReportUrl(), which swallows ONLY ERR_ABORTED and then re-waits, and
  routes gotoReports/gotoAnalytics/testPageLoadPerformance through it. Also strengthens
  the perf test: it measured elapsed time but never asserted the page rendered, so an
  instant error page would have passed the 30s budget.

Stripe block checkout — two real defects fixed, root cause still open:

* Impossible wait budget. The post-click waits were 60s (waitForURL) + 120s (settle poll)
  = 180s minimum, inside specs configured at 150s and before any setup cost. The poll,
  which is what decides pass/fail, could never run to completion on CI: the test died
  mid-poll and reported the poll's placeholder ("none") rather than a verdict. The SPA
  redirect is the known-unreliable path on CI, so it no longer gets 60s of that budget
  there (15s on CI, full 60s locally where it is the fast path), and the two affected
  specs move to 240s to match the sibling money specs.

* The suite was blind to its own failure mode. After clicking Place Order it only polled
  the REST API, so "the Store API rejected the payment" and "the click was a no-op because
  the block was not submittable" both surfaced as the same "none". placeBlockOrderExpect-
  Received now records every POST /wc/store/v1/checkout and reports it in the failure.
  That is what distinguishes product-side from suite-side on the next run.

Evidence for leaving the thirteen alone rather than patching them green: a local A/B
passes both without and with #3345 (28s / 26s), the suite's own SIMULATE_CONFIRM_BLOCK
repro also passes (35s, the fallback works), and the failing shards' databases contain
zero dokan_stripe_express orders while saved-token payments on the same shard succeed.
So the order is genuinely never created, and the cause is not yet established.

…reports redirect fix

Follow-up to bd210f5, using what that run's diagnostic reported.

The Store API instrumentation answered the open question. Across the failing shards it
printed 36 times, always the same, and never once the alternative:

    The Blocks checkout never issued POST /wc/store/v1/checkout at all — the Place Order
    click was a NO-OP (block not submittable / validation blocked it), so no payment was
    ever attempted. This is a checkout-submission failure, not a declined payment.

So no payment was ever attempted: this is not a product defect and not a declined card.
The budget change also did its job — the settle poll now reports "Timeout 120000ms exceeded
while waiting on the predicate" instead of dying mid-poll at the 150s test timeout.

Root cause of the no-op: fillCardDetails only ever re-read the card NUMBER. The method
already knows the Payment Element can re-mount mid-entry, but a re-mount after the number
is typed keeps the number populated while silently dropping expiry and CVC. That leaves an
INCOMPLETE card, so elements.submit() fails validation, WooCommerce Blocks refuses to
submit, and the Place Order click does nothing — no POST, no order, and the settle poll can
only ever report "none". It matches the observed signature exactly: zero Store API attempts
on CI, while saved-token payments on the same runner succeed because they never touch the
card fields.

fillCardDetails now verifies all three fields persisted before returning, and names the one
that was lost when it retries.

Also, when no POST is issued, the failure now reads back the block's own notice banner and
the Payment Element's inline error, so the next such failure names the offending field
instead of requiring another round trip to find out.

vendor-reports: the previous ERR_ABORTED fix was incomplete and CI caught it. Swallowing the
abort stopped goto() throwing, but waitForLoadState then resolved instantly against the
cancelled, blank document while the app's redirect was still in flight — so the assertion
added in the same commit correctly caught an empty page (bodyLen <= 50). It now polls for
real rendered content instead of a load event, which still fails if the page genuinely never
renders.

Verified locally: the six flake-fix specs are 130 passed / 4 skipped (pre-existing skips) / 0
failed, and all 13 previously-failing stripe-express tests pass. Three of those 13 initially
failed under --workers=2 on transfer contention; an A/B against the pushed revision showed
they pass with and without this change when run serially, which is how CI runs them
(playwright.config.ts sets workers to 1 on CI).

Note the limit of that evidence: local cannot reproduce the PE re-mount, so local green here
proves no regression rather than proving the fix. The added diagnostics mean the next run
either goes green or names the field that failed validation.

…m error, rebalance shards

Run 31147407922 took the branch from 14 failures to 1. The phone fix landed: every shard that
carried the Stripe block-checkout tests went green, and vendor-reports passed on its third attempt.
This clears the last failure and fixes the sharding.

SE-GUEST-01. The diagnostic message CHANGED, which is what identified this:

    before:  Block validation said: Your mobile phone number is invalid.
    now:     Block validation said: Please provide a mobile phone number.

Not invalid any more — absent. A guest has no saved address, so nothing pre-fills the phone the way
ensureCustomerAddress() does for logged-in flows; it has to be typed. fillBlockGuestDetails() had no
phone parameter at all. Added as optional, so existing callers are unaffected, and tolerant of the
field being missing when a store has the phone field switched off.

SE-GUEST-03 was passing for the wrong reason, and would have kept passing. It asserts "an inline
error appears and we never reach order-received" — which is exactly what a MISSING PHONE produces.
The declined card was never submitted, so the test proved nothing about a decline. Two changes:
the guest details now carry a phone so the decline is genuinely exercised, and
placeBlockOrderExpectError() now requires the notice to be about the payment
(/declin|card|payment|insufficient|cvc|expir/), so an address or contact validation error can never
satisfy a decline test again.

Shard rebalancing, regenerated from this run's spec-durations.json across all 12 shards (195 specs,
up from 190). The previous baseline was three weeks old (2026-07-15) and badly wrong:

    old: shards ranged 15.7 -> 86.9 min, spread 71.2 min (190% of ideal)
    new: shards range 16.7 -> 16.8 min, spread 0.1 min (0.6%)

That matches the wall-clock actually observed on CI, where one shard took 48m13s while another took
23m51s. The 18 paypal-marketplace specs are not in this run's data and fall back to the mean, which
is fine — they skip in seconds without credentials. Regenerate again once PayPal really runs.

One inflated entry to be aware of: stripeExpressGuest is recorded at 9.3 min because SE-GUEST-01
failed and retried three times in the run the data came from. It will drop once this commit is
verified green. Over-estimating a spec only spreads load away from it, so it is safe to ship.

Verified locally: tsc --noEmit at the develop baseline of 82, and the whole guest spec passes
(3/3) with the stricter payment-error assertion in place.

Review feedback on #3360: the phone belonged in test data, not inline in a spec.

It was hardcoded in seven places across five files — three billing seeds in
payloads.ts, three guest-checkout fills, the page object's customer fixture and
the orders page fixture. A single exported MOBILE_TEST_PHONE now backs all of
them.

The constant carries the reason for its value. Stripe Link validates the billing
phone as a MOBILE number and rejects the reserved fictional (555) 555-5555
range; when it does, WooCommerce Blocks refuses to submit at all, so no Store
API request fires, no order is created, and the checkout test fails with no
visible card error to point at. Without that note the value reads like an
arbitrary string and the obvious "tidy-up" to a fictional number silently breaks
the Blocks checkout again.

Keeping it in one place also means a validator change is a one-line edit rather
than a hunt across five files.

No behaviour change: same value everywhere it was already used. tsc holds at the
82-error develop baseline and the error set is byte-identical before and after.