feat(host): PyroWave capture advertises the Vulkan device's dmabuf modifiers

The pyrowave passthrough rode VAAPI's LINEAR-only modifier policy, which
starves it on Mutter+NVIDIA (tiled-only allocations → the compositor
declines the offer → CPU capture fallback). The encoder imports through
VK_EXT_image_drm_format_modifier, not libva, so the capture now extends
the advertisement with every single-memory-plane modifier the PyroWave
device samples from (probed via DrmFormatModifierPropertiesListEXT with
the same device selection as the encoder).

Live on .21 (Mutter+NVIDIA, RTX 5070 Ti): 7 modifiers advertised, the
compositor negotiated block-linear (216172782120099861), no CPU
downgrade, and the encoder's per-buffer import cache populated exactly
as designed (8 PipeWire pool buffers imported once, silent reuse after).
Zero-copy session numbers: static 60 fps, e2e 2.9-3.0 ms p50 (p95 3.4),
host stage 1.6 ms; full-window motion 60 fps at ~80 Mb/s all-intra,
decode ~1 ms. Also neutralizes the VAAPI-specific wording in the
passthrough hand-off log.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

crates/punktfunk-host/src/encode.rs

@@ -1023,6 +1023,14 @@ fn linux_auto_is_vaapi() -> bool {
     !nvidia_present()
 }
 
+/// The dmabuf modifiers the PyroWave encoder's Vulkan device imports for the capture's
+/// packed-RGB fourcc — advertised by the capture when the pyrowave passthrough is active
+/// (the VAAPI LINEAR-only policy starves it on Mutter+NVIDIA, which allocates tiled only).
+#[cfg(all(target_os = "linux", feature = "pyrowave"))]
+pub(crate) fn pyrowave_capture_modifiers(fourcc: u32) -> Vec<u64> {
+    pyrowave::capture_modifiers(fourcc)
+}
+
 /// True if the Linux GPU encode backend resolves to VAAPI (AMD/Intel) rather than NVENC — mirrors
 /// [`open_video`]'s dispatch so the capturer can choose the matching zero-copy path (raw dmabuf
 /// passthrough for VAAPI vs the EGL→CUDA import for NVENC).