surface_input: SurfaceEvent has no Scroll, though the enum docs link to it #2

Crate: gpui_interop 0.1.3 and 0.2.0 (src/input.rs).

SurfaceEvent is PointerDown | PointerMove | PointerUp (src/input.rs:121-143), but the doc comment on the enum says:

/// The event's own position is the pointer's; only a [`Scroll`](Self::Scroll) event, or a gesture a
/// producer reads from absolute positions, needs it.

(src/input.rs:117-120)

There is no Scroll variant, so that intra-doc link is broken, and every producer that wants the wheel binds its own on_scroll_wheel outside the gateway — which is what both the example and our browser viewport do (examples/interop_cube_drag.rs:20-22, :250-253, "the gateway's vocabulary carries no scroll yet").

Everything needed is already present: attach() only has to register element.on_scroll_wheel(..) next to the pointer listeners, and the platform already delivers ScrollWheelEvent { position, delta: ScrollDelta, modifiers, .. } — including the browser backend (bite-gp-web/src/events.rs:641-673). ScrollDelta has two variants (Lines, Pixels), so the producer-facing mirror is mechanical.

Suggested shape, in the crate's vocabulary:

pub enum SurfaceScroll {
    Pixels { x: f32, y: f32 },
    Lines { x: f32, y: f32 },
}

SurfaceEvent::Scroll {
    position: SurfacePoint,      // so a zoom stays anchored under the pointer
    delta: SurfaceScroll,
    modifiers: SurfaceModifiers,
}

No normalisation: consumers re-derive a notch rate anyway, and the sign is already the engine's (positive is "up", i.e. the opposite of the browser's deltaY).

We carry this in a vendored copy and exercise it from a browser probe; happy to send a PR.

Status (0.2.0, 2026-11-03): unchanged — src/input.rs is byte-identical
between 0.1.3 and 0.2.0, and the patch described here still applies
unchanged.