fix(e2e): unbreak the harness suite and make its assertions real

[CAMOBAP]

The e2e harness suite had been failing on master on every run since at least 2026-08-16.
Fixing it turned up three separate problems, one of which means the suite has never actually
verified anything.

1. The harness was installed unpinned

__scripts__/setup-e2e-host.js regenerates the host app from scratch on every CI run and
installed react-native-harness with no version constraint, so each run resolved to whatever
was newest at that moment. Upstream added a per-test testTimeout defaulting to 5000ms
(1.0.0 had no per-test timeout at all), and the suite went red with no commit in this repo.

Pinned to 1.6.0. This is the root cause — without it, any timeout fix is temporary.

2. The image assertions could not fail

failureThreshold: 5,
failureThresholdType: 'percent',

failureThresholdType: 'percent' compares differences / totalPixels — a 0–1 ratio — so 5
meant 500%, which no image pair can exceed. Every green e2e run in this repo's history
passed vacuously.

Now 0.01 (1%). For scale, the widest signal these shots carry — the light baseline against
the dark one — is 5.6% of the screen on Android and 6.3% on iOS, so 1% leaves room for
antialiasing while still catching a widget rendered in the wrong theme.

3. Each case slept through the load instead of waiting for it

await render(<WidgetFixture theme="light" />, { timeout: WEBVIEW_LOAD_MS }); // 10s
await new Promise((r) => setTimeout(r, WEBVIEW_LOAD_MS));                    // + 10s

render's timeout only covers React commit plus a double rAF — it does not wait for the
WebView to fetch anything, so the 10s there was decorative and the real wait was the blind
10s sleep. ~94% of each test's duration was that sleep.

Replaced with a signal-driven wait. Hcaptcha.js gains a testID on the loading overlay,
which is torn down when the page posts its first message, making its absence the one readiness
signal a UI-level test can observe. The wait also inspects onMessage on every poll, so an
SDK error fails the test with the SDK's own description rather than diffing a screenshot of a
spinner.

The readiness cap is 20s, deliberately above the SDK's own 15s loadingTimeout: when the
page never comes up we want loading timeout reported through onMessage, not the harness
killing the test with an opaque message.

testTimeout: 60000 stays as a backstop — it must live in rn-harness.config.mjs, which is
where the harness actually reads it.

Stability

Five sequential CI rounds on 58135e3 (Android ×5, iOS ×4 — 18 assertions): all green, no
retries, no flakes.

                  min     max     mean
Android  light   2761    5244     4287
Android  dark    2790    4942     3767
iOS      light   4089    6025     4750
iOS      dark    1859    2531     2133

Durations fell from ~10.7s to ~1.9–6.0s, and worst case is ~10% of the 60s backstop. The
spread is the intended consequence of waiting on a signal rather than a clock — runner noise
now shows through in duration, not in outcome.

Most importantly: these are the first runs in which the baselines were genuinely compared.
They held on both platforms.

Follow-up worth doing separately

screen.screenshot() accepts an element reference, and cropping to the widget raises the
light-vs-dark signal from ~5.6% to ~92.5%. Left out here because it changes the captured
dimensions and requires re-recording all four baselines on a real emulator and simulator.

🤖 Generated with Claude Code