v4l2: raise the capture buffer cap from four to eight

[vrilutza]

The four-context limit prevents clients from allocating a deeper capture queue even when the 16 MiB budget can hold more frames. If a consumer retains all four buffers, the camera has none available for another frame.

This revision has two commits:

1. Correct the buffer-queue debug message to read descriptor zero of the current buffer's list. The old code uses the capture-context slot as an index into a four-element descriptor array. Increasing the context count to eight therefore makes debug logging read outside that array for slots 4–7.
2. Raise FTHD_BUFFERS from four to eight. The allocation budget still limits the actual count; eight 1296x736 YUYV buffers fit within it.

The descriptor correction is new relative to the previous one-line PR. An extracted UBSan check reproduces the old out-of-bounds access at index four and passes with descriptor zero. The corrected combined series also captured using all eight buffer indices, with no V4L2 buffer error flags in the recorded tests.

This raises the permitted queue depth. It does not guarantee that every PipeWire client negotiates eight buffers, and retaining all eight still stalls capture. The cumulative CREATE_BUFS accounting correction is in #342; the eight-buffer tests quoted here used that correction as part of the combined series.

Validation scope: this individual rebased branch builds against Linux 7.1.13+deb14-amd64 with W=1; the two existing compiler warnings remain. The complete nine-topic series previously passed 57/57 streaming-inclusive v4l2-compliance checks on MacBookPro14,1. Its final source tree is unchanged by the commit-message rewrite. The combined hardware tests are not nine separate hardware certifications, and no new module reload or hardware test was performed for this publication.

Revision: b1a9b40bb3d4130808a15f39cb189d81a4ba69c5.