fix(vision-mixer): use gpu-aware videoconvert in CPU pipeline

[srperens]

Summary

The CPU compositor path in the vision mixer hardcoded plain videoconvert for the DSK, overlay, and video-input chains. When an upstream source produces GPU memory (e.g. nvh264dec fed from efpsrt_input), plain videoconvert cannot negotiate against the CPU compositor backend and the pipeline fails to link.

This PR switches all three chains in build_cpu_pipeline to gpu::video_convert_mode().element_name(), matching the pattern already used by the videoenc, videoformat, decklink and ndi blocks — autovideoconvert on hosts with working CUDA-GL interop, plain videoconvert everywhere else.

The selection is computed once at startup in backend/src/gpu.rs:42 based on WSL detection, GL renderer probing, and CUDA capability checks.

Why this is safe

• CPU-only hosts behave identically — video_convert_mode() returns Software, which maps back to plain videoconvert.
• Consistent with existing convention — videoformat.rs:107, decklink.rs:55,255, ndi.rs:209 already use the exact same helper. Vision mixer was the only hold-out.
• No tests reference "videoconvert" by string, so the rename does not break the existing vision_mixer/tests.rs assertions.
• Only the CPU pipeline branch is touched (build_cpu_pipeline, line 581+). The GPU pipeline (build_gpu_pipeline, line 242+) is untouched.
• No code sets properties on these specific converter elements after construction, so the fact that autovideoconvert (a bin) does not expose the same properties as plain videoconvert does not matter.

Risks worth watching

• On a NVIDIA + working-interop host, sanity-check that autovideoconvert correctly inserts cudadownload when downstream is the CPU compositor (it is designed to, but worth a quick eyeball during the first run).
• autovideoconvert is a bin and adds a small amount of probing at element creation; negligible for typical input counts.

Test plan

• cargo build --release --features efp,nvidia clean
• On a CPU-only host: build a vision-mixer flow with multiple inputs, start it, verify no CAPS negotiation errors in the log
• On a NVIDIA host with nvh264dec upstream (e.g. via efpsrt_input): same flow, verify the pipeline links and runs without errors
• Verify existing vision_mixer/tests.rs still passes

🤖 Generated with Claude Code