windows-ui: PdfView is a placeholder STATIC label — no real PDF rendering

[proggeramlug]

PdfView on Windows is a stub-with-state: a STATIC control showing [PDF: name — page X/Y @ Z%], with page state tracked but no page pixels ever rendered. macOS backs the same widget with PDFKit, so cross-platform apps using PdfView get a text label instead of a document on Windows. Found in the 2026-07-18 Windows audit (main @ 58e555e).

Evidence

• crates/perry-ui-windows/src/widgets/pdf_view.rs:1-9 — module doc: STATIC control showing "[PDF: filename] page X of Y"; rendering deferred.
• crates/perry-ui-windows/src/ffi/rich_pdf_map.rs:38-40 — "PdfView (API for creating PDF reports and a Pdf Viewer widget #516) — Win32 stub-with-state... Real page-bitmap rendering... is a follow-up."

Suggested fix

Render real pages via WinRT Windows.Data.Pdf (PdfDocument -> page bitmap blitted into the control), or host WebView2 and use its built-in PDF viewer.

[proggeramlug]

Revalidated against current main while processing the oldest Windows tickets. This is still current: the Windows backend remains a stateful STATIC-label placeholder and does not render PDF pages. I found no assignee or active PR. Keeping it open—the correct fix needs a substantive WinRT Windows.Data.Pdf or WebView2 rendering backend, not a stale/no-op closure.

[proggeramlug]

Closed by #8717, landed on main via #8721 (squash 3f655301e).

That PR was landed through a batch wrapper PR rather than merged directly, so GitHub's close keyword never fired at merge time. Verified before closing: the Windows.Data.Pdf render path is on main in crates/perry-ui-windows/src/widgets/pdf_view.rs, replacing the STATIC-label placeholder.