fix(pf-encode): gate forced_split_width to Linux — WP4 broke the Windows build

The verification gap flagged in 01294e3a was real. `.133` came back up and the
WP4 commit failed Windows clippy: `forced_split_width` is used only by the libav
NVENC path (`enc/linux/mod.rs`), but it was added to `codec.rs`, which compiles
everywhere -- so it is dead code on Windows and `-D warnings` rejects it.

Third time this crate has hit the same item-level dead_code trap (see
`subframe_env_forced`, and the arbiter items in `nvenc_core`), and the third time
it was caught by actually running the Windows check rather than by reasoning
about it. The comment on the gate says so, since the pattern is clearly not
self-evident from the code.

Verified .21: clippy -D warnings clean both WITH and WITHOUT the nvenc feature,
65 unit tests. Verified .133: Windows clippy --features nvenc --all-targets
-D warnings clean, zero errors, zero dead_code. fmt clean.

crates/pf-encode/src/enc/codec.rs

@@ -654,6 +654,11 @@ pub(crate) fn max_forced_split_mode(engines: u32) -> u32 {
 /// For callers that can only express "split this many ways" and have no vocabulary for our other
 /// modes — the libav path, whose `split_encode_mode` AVOption is libavcodec's own enum, not the
 /// NVENC one (our `DISABLE` is `15`, which would be meaningless there).
+// Linux-only: its sole caller is the libav NVENC path (`enc/linux/mod.rs`). `codec.rs` compiles
+// everywhere, so without this it is dead code on Windows — the same item-level `dead_code`
+// trap this crate has now hit three times (see `subframe_env_forced`, and the arbiter items in
+// `nvenc_core`). Caught by the `.133` check, never by reasoning about it.
+#[cfg(target_os = "linux")]
 pub(crate) fn forced_split_width(mode: u32) -> Option<u32> {
     match mode {
         m if m == SPLIT_TWO_FORCED => Some(2),