Web target is second-class — track parity work

[KealanAU]

Vy UI is native-first. The Web target works as a preview surface but isn't a parity target. Tracks the work to bring it up.

• pluginWebPlatform() from @lynx-js/web-rsbuild-plugin is not added to example lynx.config.ts files (demo, tailwind)
• Touch worklets dead on Web (folded in from [upstream] Touch worklets on <view> don't propagate on Lynx Web #4, upstream-blocked) — :main-thread-bindtouch* handlers on a plain <view> don't fire on the Lynx Web target. Entry/exit springs animate fine, but drag is dead. Native iOS/Android work as expected. Affects Sheet, Swiper, Slider, SwipeAction (when ported), Sortable/Draggable (when built). Surfaced by motion PR cbfb803. Until upstream propagates touch events to worklets on Web, all drag-physics components are mobile-native-only.
• No cross-target test matrix (iOS / Android / Web)
• Tap-driven components (Dialog, Tabs, Accordion, Switch) work on Web today; gesture-driven do not
• apps/examples/ui-demo/ runs as the desktop/web surface; native-demo / linear-demo are touch-only by design

Decide: do we publicly claim Web parity for tap-driven components only, or invest in lifting gesture components onto a Web-compatible path (mouse polyfill + pointer events)?

Related

• [upstream] Component animations limited until element.animate() / CSS keyframe parity lands across all Lynx targets #20 — animation parity (element.animate() across targets)
• [upstream] Worklet/MTS toolchain limitations (umbrella) #50 — worklet/MTS toolchain umbrella