Purge vestigial client-side SetDpi calls (Dxui layout pass owns DPI)

[relmer]

DPI propagation is owned by Dxui: every widget's IDxuiControl::Layout override adopts the incoming scaler (m_scaler.SetDpi (scaler.Dpi())), and DxuiHwndSource pushes its authoritative scaler through the panel tree on creation and on every resize / DPI change, before first paint. Clients of Dxui should not think about DPI at all.

A number of call sites still carry per-control SetDpi calls from before that contract existed (the "seed DPI before Create so the first frame isn't 96-DPI" era). They are dead weight today and invite cargo-culting into new code — the create-disk dialog picked them up by copying the picker idiom before they were removed there (70e07985 cleaned that dialog).

Remaining call sites to audit and remove (counts per file, current 017-blank-disk-creation tip):

• Casso/EmulatorShell.cpp (7)
• Casso/AssetBootstrap.cpp (2 — DiskMruPickerSession, the idiom the create dialog copied)
• Casso/Ui/Settings/ColorPickerOverlay.cpp (4)
• Casso/Ui/Settings/HardwarePage.cpp (4)
• Casso/Ui/Settings/ThemePage.cpp (4)
• Casso/Ui/Settings/DiskPage.cpp (2)
• Casso/Ui/PrinterPaperView.cpp (1)

Notes for the cleanup:

• Each site needs a quick check that the widget actually lives in a laid-out panel tree before the removal; anything measured before its first layout (or living outside a tree) is a genuine consumer and should be called out instead of removed.
• Chrome that self-manages a scaler outside the tree (drive band, toolbar) may be legitimately DPI-aware; the audit should distinguish those from true leftovers.
• Once clean, consider making the widget-level SetDpi setters non-public (or renaming to something internal) so the pattern cannot creep back.

Mechanical, but touches shipped dialogs — run the full validation loop (x64 Debug + Release suites, quick visual pass at 200% scaling) on the sweep.