M10: adopt file-backed loading and record review fixes in the progress log

docs/windows-printing.md

@@ -4,16 +4,16 @@ A report on PdfCraft 0.19.0 described the preview closing without output while E
 
 The native submission test failed before queueing: `StorageFile::GetFileFromPathAsync` returned `0x80070005` for the temporary PDF. Ordinary desktop file access could read it. This isolates one reproducible failure; it does not establish the cause of every report of an empty print queue.
 
-The winprint loader reads the job using desktop file access, transfers it in 64 KiB chunks to an `InMemoryRandomAccessStream`, and calls `PdfDocument::LoadFromStreamAsync`. It does not fall back to another printer or retry an already submitted job. Tickets, layout, permissions and completion handling remain in place. The stream still holds the PDF in memory; large-job memory use needs qualification.
+The winprint loader uses `CreateRandomAccessStreamOnFile` with read-only access, then calls `PdfDocument::LoadFromStreamAsync`. The stream is backed by the job file and reads on demand. There is no whole-job `InMemoryRandomAccessStream` copy, `DataWriter`, transfer loop or per-chunk `StoreAsync().join()`. The path is made absolute and embedded NUL characters are rejected before calling the native API. The temporary file remains alive throughout rendering and submission through craft-print's existing lifetime management. PDF decoding and rendering can still allocate memory; the change removes the loader's full-file copy, not all printing memory use.
 
-Upstream fix: https://github.com/storytold/winprint.rs/pull/15. PdfCraft now updates only its `craft-print` dependency, with no global `[patch]` override. Both printing libraries are pinned to winprint `17f5f1e3`, a child of `64e7afd4` containing the multi-threaded Direct2D factory fix for #5006. All Git source URLs remain under `storytold`; the dependency follow-up is https://github.com/storytold/craft-libs/pull/636 (stacked on #605). Upstream reviews are still required before release.
+Upstream loader: https://github.com/storytold/winprint.rs/pull/15 (`b334ebbb`). Dependency follow-up: https://github.com/storytold/craft-libs/pull/636 (`93d7c7b5`, stacked on #605). PdfCraft updates only its normal `craft-print` dependency. There is no global patch or personal-fork source. The loader revision descends from `64e7afd4`, preserving the multi-threaded Direct2D factory fix for #5006. Upstream reviews are still required before release.
 
 ## Evidence
 
-- Existing Windows loader: synthetic A4 job failed at PDF loading with `0x80070005`.
-- Stream loader: same HUAWEI job returned `spooled 1 sheet(s)`.
-- No-printer regression: existing test PDF in a hidden temporary file fails under the old loader and passes under the new one.
-- 14 Print Schema reader/writer tests passed. Wider native ticket tests require installing a null printer; 13 failed because Add-Printer was denied (20 passed).
-- Physical paper output and a packaged 0.19.0 application build have not been independently verified. A successful queue submission is not proof of physical printing.
+- Original Windows loader: synthetic A4 submission failed at PDF loading with `0x80070005`. The earlier memory-stream prototype submitted the same HUAWEI job; physical output was not independently confirmed.
+- Final file-backed loader: five focused tests pass, covering a hidden PDF, read-only stream behavior, reading the final byte of a 256 MiB file, a missing file, and a path containing NUL.
+- The hidden-file test was observed failing with the original StorageFile loader. The read-only test was observed failing with the earlier in-memory implementation and passing with the final loader.
+- Isolated craft-print suite with the final loader and multi-threaded Direct2D source: 63 passed, 3 hardware tests ignored. These diagnostic tests are not a full build of the final dependency graph; the disabled PDFium downloader build dependencies were omitted locally.
+- Full final-graph build/quality gates remain subject to CI. A packaged 0.19.0 application and physical paper output with the final loader have not been independently verified. Submission success is not proof of physical printing.
 
 When reporting a different failure, include the PdfCraft version, printer/driver name, displayed error and whether a job appears in the Windows queue. Saving the print-ready PDF and printing it in another viewer remains a workaround until the fix ships.