chore(web): enforce browser compatibility policy

[kiftio]

Summary

Establishes an enforceable browser-compatibility contract for the Web package.

• Declares the initial supported browser floor: Chrome, Android Chrome, Edge, Firefox, and Android Firefox 111+, plus Safari and iOS Safari 16.4+.
• Derives Vite/esbuild build targets from that policy.
• Adds an ESLint compatibility check over runtime Web source, so unsupported browser APIs fail linting.
• Documents the supported-browser policy in the Web README.
• Updates the checkout E2E selector for the Contact field.

This is an intentionally modern initial baseline. It remains higher than a broader compatibility baseline used by other checkout surfaces, while turning our existing Safari/iOS 16.4+ commitment into a concrete, enforceable cross-browser policy.

No runtime compatibility regression was found in the before/after build comparison: the PR base and head produce byte-for-byte identical dist/index.js. The new checks enforce the declared policy during linting and compilation; they add no runtime browser-version gate. This verifies unchanged shipped JavaScript, rather than claiming exhaustive testing of every legacy browser.

We evaluated a lower native-feature-based floor. It added about 7.4 kB raw / 1.5 kB gzip to the bundle, largely from downleveling private class fields to WeakMap/WeakSet state and lowering other modern syntax. A follow-up can revisit broader support and differential delivery if there is a product requirement for it.

Validation

• dev web lint
• dev web test
• dev web build
• Before/after bundle comparison: base f245de7 vs head a781034; both builds passed and dist/index.js is byte-for-byte identical (34,073 bytes, matching SHA-256).

[github-actions]

Web — Coverage Report

Lines	Statements	Branches	Functions
	95.16% (374/393)	84.32% (199/236)	97.08% (100/103)

[github-actions]

Package Size

Platform	Artifact	Base	Head	Delta
Web	npm tarball	89.4 KiB	89.5 KiB	+121 B

Web file breakdown

File	Base	Head	Delta
dist/index.js.map	249.1 KiB	249.0 KiB	-65 B
dist/index.d.ts	47.9 KiB	47.9 KiB	0 B
dist/custom-elements.json	47.5 KiB	47.5 KiB	0 B
dist/index.js	33.3 KiB	33.3 KiB	0 B
README.md	20.1 KiB	20.2 KiB	+114 B
package.json	3.2 KiB	3.6 KiB	+424 B
LICENSE	1.1 KiB	1.1 KiB	0 B

Measured from the PR base SHA and PR head SHA. The file breakdown shows uncompressed sizes within each package artifact, so individual files do not sum to the compressed artifact total. This comment reports package artifact sizes only; it is not a final app binary-size report.

[bitrise]

Install this build

Open Tophat, select your target device, then click Install. Links open on the Mac running Tophat.

SDK	Install
React Native	Install with Tophat
Swift	Install with Tophat
Kotlin	Install with Tophat

Checkout Kit E2E results

Status	Tags	Target	Platform	OS version tag	Device
✅	launch, checkout-presentation, checkout-completion, buyer-identity	react-native	ios	latest	iPhone 15 iOS 27 Beta
✅	launch, checkout-presentation, checkout-completion, buyer-identity	react-native	android	latest	Google Pixel 9 Android 17.0
✅	launch, checkout-presentation, checkout-completion, buyer-identity, preload	kotlin	android	latest	Google Pixel 9 Android 17.0
❌	launch, checkout-presentation, checkout-completion, buyer-identity, preload	swift	ios	latest	iPhone 15 iOS 27 Beta

Failures

Caution

If you believe an assertion is flaky, please raise a ticket in the #checkout-kit-devs channel so it can be addressed.

BrowserStack artifacts require BrowserStack access. Sign in to BrowserStack App Automate before opening artifact links.

iOS — swift

Test	Status	Artifacts
./tests/shared/checkout-hardcoded-buyer-identity	❌	BrowserStack · Video · Screenshot · Maestro commands · Maestro log

[kiftio]

Follow-up discussion: browser support and delivery

This PR establishes a deliberately modern npm baseline and does not introduce multiple browser artifacts.

A lower browser floor is feasible, but makes the single shipped bundle about 1.5 kB gzip larger because of syntax transforms, particularly private class fields. A future CDN path could instead use a stable public loader that selects a modern or baseline implementation artifact at runtime, so modern browsers avoid that cost.

Questions for follow-up:

1. Is the initial 111 / Safari-iOS 16.4 floor the right npm support contract?
2. Do we have a product requirement for broader browser support?
3. If so, should CDN delivery eventually provide modern/baseline artifacts while npm remains one modern self-contained ESM package?