docs: state the browser engine boundaries

[cardmagic]

The support matrix said only "Chromium through Playwright", which leaves the most common adoption question unanswered: does the browser runtime work in my WebView? An agent evaluating the library for a Cordova/WKWebView app hit exactly that wall.

docs/support.md now answers it in three parts:

• What gates persistence: OPFS sync access handles in a dedicated worker — Chromium has them, Safari since 16.4, Firefox since 111.
• What the multi-tab hosts need: the Web Locks API and BroadcastChannel, available in every current engine.
• Why a WebView is not the platform browser: Cordova and other WKWebView or Android WebView shells can lack OPFS even when the device's browser has it. sqliteWasm({ storage: "persistent" }) fails fast where OPFS is missing and temporary storage works wherever the WASM module loads, so the note prescribes probing the target WebView before committing to durable in-app state.

Docs-only; check:documentation passes.

[greptile-apps]

Greptile Summary

Adds browser-runtime support boundaries and deployment guidance to the support documentation.

• Identifies OPFS sync access handles as the persistent-storage requirement.
• Documents the Web Locks and BroadcastChannel requirements for multi-tab hosts.
• Warns that embedded WebViews may differ from platform browsers and recommends probing the target runtime.

Confidence Score: 5/5

The documentation-only PR appears safe to merge.

The added guidance accurately distinguishes persistent OPFS storage, temporary storage, and multi-tab browser requirements without changing runtime behavior or introducing a documented contradiction.

Important Files Changed

Filename	Overview
docs/support.md	The new browser compatibility guidance is consistent with the repository’s direct SQLite WASM and multi-tab host behavior; no actionable issue was identified.

_{Reviews (1): Last reviewed commit: "docs: state the browser engine boundarie..." | Re-trigger Greptile}