fix(encode/windows): two dead items the new lint leg exposed in the shipped combo

09aa2db3 turned on `-p pf-encode --all-targets -D warnings` for Windows and removed
the crate-wide `allow(dead_code)`; together those surfaced two genuinely-dead items
in `nvenc,amf-qsv,qsv` — the combination the installer ships — and CI went red on my
own step.

  - `WinVendor::Amf`: native AMF replaced the libavcodec AMF path in production, so
    the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]` latency A/B
    in amf.rs — test code, so the lib target constructs it nowhere. The module
    header already says this machinery is kept deliberately for that measurement, so
    it gets a targeted `#[allow(dead_code)]` naming the reason rather than deletion.
  - `probe_can_encode`: `lib.rs`'s only caller is under
    `cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native
    VPL backend compiled in `qsv::probe_can_encode` answers instead. Gated
    `#[cfg(not(feature = "qsv"))]` to match its call site.

Both are real findings the blanket allow had been hiding; neither is a behaviour
change.

WHY THIS ESCAPED MY PRE-PUSH CHECKS, since that is the useful part: the Windows
runner I verify on has no FFmpeg dev tree, so `amf-qsv` could not build there and
`ffmpeg_win.rs` was compiled by NOTHING in my matrix — the same class of blind spot
this whole audit is about, reproduced by me. CI's own FFmpeg turns out to be cached
on that box at C:\Users\Public\ffmpeg, so the verification recipe now sets
FFMPEG_DIR and covers `nvenc,amf-qsv,qsv` (the CI command and my new step) plus
`amf-qsv` without `qsv` — the combo that still uses `probe_can_encode`. All three
clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

crates/pf-encode/src/enc/windows/ffmpeg_win.rs

@@ -95,6 +95,13 @@ struct AVD3D11VAFramesContext {
 /// AMD AMF vs Intel QSV — the two libavcodec vendor backends this module covers.
 #[derive(Clone, Copy, Debug, PartialEq, Eq)]
 pub enum WinVendor {
+    /// Benchmark-only, as the module header explains: native AMF replaced the libavcodec AMF path
+    /// in production, and the only remaining CONSTRUCTOR is the `#[cfg(feature = "amf-qsv")]`
+    /// latency A/B in `amf.rs` — the measurement that justifies the native backend existing. That
+    /// is test code, so the *lib* target constructs it nowhere and `dead_code` fires on it (the
+    /// crate root no longer blanket-allows that). Kept deliberately rather than deleted; the arms
+    /// below are what the benchmark drives.
+    #[allow(dead_code)]
     Amf,
     Qsv,
 }
@@ -277,6 +284,11 @@ pub fn probe_can_encode_444(_vendor: WinVendor, _codec: Codec) -> bool {
     false
 }
 
+/// Gated to the builds that can actually reach it: `lib.rs`'s only caller sits under
+/// `cfg(all(not(feature = "qsv"), feature = "amf-qsv"))`, because with the native VPL backend
+/// compiled in it is `qsv::probe_can_encode` that answers. So in the SHIPPED Windows combo
+/// (`nvenc,amf-qsv,qsv`) this function has no caller at all.
+#[cfg(not(feature = "qsv"))]
 pub fn probe_can_encode(vendor: WinVendor, codec: Codec) -> bool {
     // Deliberately NOT pinned to the selected render adapter (unlike `nvenc::probe_can_encode_444`):
     // the system-input probe passes no hwdevice, and the AMF/QSV runtimes only ever bind their own