Add WebKit/Safari to e2e + decide the supported-browser stance

[BorisTyshkevich]

Part of #68 (Roadmap to 1.0.0) — release-blocker.

Problem

e2e runs only Chromium + Firefox (playwright.config.js projects; .github/workflows/ci.yml installs chromium firefox). The entire layout and pointer/caret/drag math rides on html { zoom: var(--zoom) }, and WebKit/Safari — the engine most likely to diverge on zoom × getBoundingClientRect/viewport units — is the one not tested. A 1.0 must know whether it works on Safari.

Ask

• Add a webkit Playwright project and a CI job that runs the existing e2e specs on it (npx playwright install webkit).
• Run the schema-graph / editor-alignment / pipeline specs on WebKit and record pass/fail.
• Make an explicit decision: Safari supported (fix what breaks — see #zoom-deps issue) or explicitly unsupported (documented in the support matrix).

Acceptance

• webkit project in playwright.config.js; CI runs it.
• e2e green on WebKit, or breakages triaged and either fixed or the engine declared unsupported.
• Decision recorded and fed into the browser support matrix.

Closely related to the html{zoom} de-risk issue and the support-matrix issue below.

[BorisTyshkevich]

Prioritize as a do-now baseline, before the editor/graph refactors (CM6 #21, #66) churn the coordinate paths. playwright.config currently runs chromium + firefox only; add a webkit project so Safari regressions are caught before the refactors, not after. Pairs with #70.

[BorisTyshkevich]

Implemented — PR up.

Outcome / decision: Safari (WebKit) is supported. Added a webkit Playwright project and wired it into the CI e2e job (playwright install --with-deps … webkit), so the existing render-layer specs run on three engines on every push/PR.

Empirical result (the point of this issue): WebKit launches only on the Linux CI runners (the frozen mac14-arm64 build SIGTRAPs under the dev sandbox — so do chromium/firefox locally; these have always been Linux-CI-only). On CI: 36 passed (20.0s) = 12 specs × 3 engines, WebKit included — the editor-alignment (html{zoom} × getBoundingClientRect/scrollbar math), editor-insertion (execCommand), schema-graph, and EXPLAIN-pipeline pan/zoom specs all pass on WebKit. CI run.

So the html{zoom} reliance does not break Safari for the tested surfaces — and a future regression that would break Safari now fails CI instead of shipping silently.

Decision recorded: README → new Supported browsers section; CHANGELOG [Unreleased]; browser row fed into the support-matrix issue #71.