docs(linux): add the camera-enumeration WebKit crash

[jramiresbrito]

Summary

Documents a WebKitGTK crash that presents as a hang, so Linux users can identify
it in one command and work around it today. Docs only — no code changes.

Found while debugging #6339. The root cause is upstream in WebKit, not in Buzz;
this adds the detection steps and workaround while that is fixed.

What happens

When a page calls navigator.mediaDevices.enumerateDevices(), WebKit builds
video presets for every capture device it can see.
GStreamerVideoCaptureSource.cpp handles a framerate that is a fraction range
or a single fraction, and otherwise assumes a list. When the field is absent,
gst_structure_get_value() returns NULL and gstStructureGetList() aborts the
web process on a RELEASE_ASSERT that sits one line above its own graceful
early-return:

const GValue* list = gst_structure_get_value(structure, key.utf8());
RELEASE_ASSERT(GST_VALUE_HOLDS_LIST(list));   // kills the web process
if (!GST_VALUE_HOLDS_LIST(list)) {            // unreachable
    GST_WARNING("Structure field %s does not hold a list", key.utf8());
    return result;
}

Symbolicated from a core dump:

#2  abort ()
#3  WTFCrashWithInfo(int, char const*, char const*, int)   WTF/Assertions.h:987
#4  gstStructureGetList<double>()                          GStreamerCommon.cpp:1460
#5  generatePresets()                                      GStreamerVideoCaptureSource.cpp:326
#8  capabilities()                                         GStreamerVideoCaptureSource.cpp:256
#25 enumerateDevices()                                     RealtimeMediaSourceCenter.cpp:307

Intel IPU6 laptops trigger it because the sensor is published twice — once via
icamerasrc/v4l2loopback, which is fine, and once via libcamera with no
framerate field.

Why it is worth documenting separately

It does not look like the other entries in this guide. The window paints
normally, then freezes on whatever it last drew roughly 20-30 seconds later.
Buzz prints nothing, and any "is the web process alive?" check in the first
~15 seconds reports healthy. It reads as a hang or a slow network, so the
existing rendering sections do not lead anyone to it.

Verified on

• Dell XPS 9320, Intel IPU6 (ov01a10), Ubuntu 26.04, GNOME/Wayland
• webkit2gtk 2.52.3-0ubuntu0.26.04.3
• Buzz 0.5.17 (deb) and 0.5.18 from source, both affected
• Before the workaround: crashed 6/6 launches
• After: stock .deb, clean environment, 5/5 launches loaded the UI and were
  still alive at 60s

The workaround leaves the working camera in place — on IPU6 the capture path is
icamerasrc → v4l2loopback, which does not involve libcamera.

Upstream

The fix belongs in WebKit: drop the RELEASE_ASSERT so the existing
GST_WARNING and early return can skip the device instead of killing the
process. Still present on WebKit main (GStreamerCommon.cpp:1403-1408).
bugs.webkit.org was unreachable at the time of writing; I will file it there
once it is back.

Refs #6339