Fix Wayland VA-API capture of DMA-BUF frames

[purpleempress]

Wayland capture on Intel Lunar Lake fails on current main (ae06722) when using vah264enc. The pipeline emits one small initial frame, then exits with vapostproc: Invalid caps video/x-raw(memory:DMABuf) and a PipeWire internal stream error.

This adds a VA-API capture path that imports the portal buffers directly and keeps conversion, scaling and encoding in VA memory. vapostproc produces a separate NV12 surface, so downstream elements do not retain another portal buffer. PipeWire keepalives supply idle frames, and videorate limits the output rate. The shared encoding and timestamp-preserving output remain unchanged.

The source caps also specify square pixels. Without that constraint, this setup negotiated a pixel aspect ratio of 1/2147483647, which prevented vapostproc from calculating the borders needed to preserve the desktop's proportions.

Validation:

• go test ./... passes, including regression coverage for the VA pipeline, receiver dimensions and shared output.
• Live GNOME Wayland portal capture produced 300 encoded frames at 1920×1080/30 fps. Decoding confirmed desktop content and correct proportions.
• Tested with Intel Lunar Lake graphics, GStreamer 1.28.2 and Intel media driver 26.1.2.

This validation covers local capture and encoding. Verified working on a Samsung AU9000 in conjunction with PR #44, Other VA-API drivers have not been tested.

[alchemy]

This PR exposes a problem in daemon mode: shared-video queue allows only two frames at 30 fps; a short encoder burst overflows it and produces a misleading capture-EOF error.

[purpleempress]

@alchemy Would you mind verifying now? I only use it in single-target daemon mode, but I've added a separate 250ms burst budget for the shared queue and overflow should now report a backlog error rather than capture EOF. Tests (with race detector) and go vet pass.