WPE inline browser may overdraw when scrolled past a window edge (clip_rect discarded)

[tag-und-nacht]

Noticed while working on the macOS WKWebView backend in #297 and not
forced, because the macOS route never enters content.rs — it positions a
native NSView rather than drawing a quad. Filing it so it does not disappear
with that PR's description. It needs someone with a WPE-enabled Linux build to
confirm or refute.

The asymmetry

There are two places that turn a FrameGlyph::Xwidget into a quad, and only
one of them honours the clip:

• neomacs-renderer-wgpu/src/renderer/layer_media.rs:414 destructures
  clip_rect and uses it — cropping the quad and adjusting the texture v
  coordinates so the visible part still samples the right rows.
• neomacs-renderer-wgpu/src/renderer/content.rs:1800 destructures the same
  glyph with .., discarding clip_rect, and pushes a full-size
  textured_quad_vertices(wx, wy, *width, *height, 0.0, 1.0).

So whether a WPE view is clipped depends on which of the two paths draws it.

FrameGlyph::Xwidget carries a clip_rect for the same reason the image and
video glyphs do, and the macOS backend consumes it (it is GNU's
clip_left/clip_right/clip_top/clip_bottom from
x_draw_xwidget_glyph_string, src/xwidget.c:2841-2849). The WPE path ignoring
it looks like an oversight rather than a decision.

What it would look like if real

A WPE inline browser scrolled so that part of it falls outside its window's text
area would overdraw — painting over the neighbouring window, the mode line, or
the fringe — instead of being cropped at the window edge. Split the frame,
put an xwidget-webkit buffer in one window, and scroll it so the widget
crosses the window boundary.

This may already be covered by a pass-level scissor set elsewhere in the
render pass, in which case the fix is a comment saying so rather than code. That
is the first thing to check.

Scope

Small and self-contained, independent of the macOS work in #297, and Linux-only.