fix(pf-dxvadec): a wrapped sentence turned "6." into an ordered list

A doc paragraph in `pic_av1.rs` wrapped so that "first at frame / 6. Releasing…"
put `6.` at the start of a line. rustdoc reads that as an ordered-list item
starting at 6, which makes the following unindented `///` line a lazy
continuation — `clippy::doc_lazy_continuation`, denied by `-D warnings`.

Reflowed so the number cannot begin a line. Prose is byte-identical in content;
only the wrap points move. No code, no behaviour.

WHY THIS MATTERS FOR THE TAG. `pf-dxvadec` is Windows-only, and no Windows leg
runs on a push to main — so main being green proves nothing about this. The
failure surfaces for the first time in a release tag's fan-out, which is exactly
what happened to the FIRST v0.23.0 tag: it went red on Windows clippy for this
same lint, and the cure was a tag re-point.

Caught pre-tag by re-running the lazy-continuation scanner over the tree while
preparing v0.25.0 (0 hits before this commit's parent merged the new decode
crates, 1 after). Cannot be verified by compiling here — the crate does not build
on macOS — so the evidence is the scanner plus the lint's own rule, not a clippy
run.

crates/pf-dxvadec/src/pic_av1.rs

@@ -129,10 +129,10 @@ pub struct DecodePlanDxvaAv1 {
     /// AV1 applies `refresh_frame_flags` AFTER the frame is decoded (7.20), so
     /// `ref_frame_idx` resolves against the store as it stood BEFORE this frame and
     /// a frame that reads a slot it then overwrites is the ORDINARY case, not an
-    /// exotic one: **268 of the vendored vector's 274 frames** do it, first at frame
-    /// 6. Releasing such a picture inside this conversion — which is what the H.264
-    /// and H.265 siblings do with their whole `removed` list, and what this one did
-    /// until the parity harness caught it — hands its surface straight back to
+    /// exotic one: **268 of the vendored vector's 274 frames** do it, first at
+    /// frame 6. Releasing such a picture inside this conversion — which is what the
+    /// H.264 and H.265 siblings do with their whole `removed` list, and what this
+    /// one did until the parity harness caught it — hands its surface straight back to
     /// [`Self::setup_slot`], because [`SlotMap::assign`] takes the lowest free slot
     /// and the lowest free slot is the one just vacated. The submission then says
     /// `CurrPicTextureIndex = N` and `RefFrameMapTextureIndex[k] = N` in the same