QuickLook-Next 5.5.0

Mixed-DPI placement is testable now, not just "trusted"

5.0.10 and 5.2.0 fixed two upstream issues —#827
(the preview window spanned several monitors on mixed-scaling setups) and
#1956 (Markdown kept the old scale after a
display-scaling change). The machine in that report has two screens; the development machine has
one, so the evidence stopped at "the maths is right and a single screen behaves as before".

The placement rule is a pure function now. The 9/10 layout in ViewerWindow (grow or shrink
around the old centre, anchor on the old edge, pull back inside) moved to
QuickLookNext/Helpers/WindowPlacement, so mixed-DPI geometry can be tested without a second
screen. Four new unit tests use the geometry from that bug report (4K at 250% next to 1080p at
100%):

• a window in the left third keeps its left edge;
• a window in the right/bottom third keeps its right/bottom edge;
• a window in the middle is pushed back inside;
• and the full pipeline —clamp the size to the screen, then place it— puts a 2600x1400 DIP
  window clamped to 1920x1080 at (0,0) with all four edges inside.

Writing those tests turned up a real edge case: the right/bottom anchors position the window
from the old right/bottom edge, so a window that grows a lot is pushed off the opposite side
(measured: a window clamped to the width of a 250% panel hung 72 px off the left edge). Placement
now pulls the result back inside once more at the end. It is a no-op whenever the window fits, so
the anchor behaviour is unchanged.

New: /test-monitor-refit (a per-screen report)

For checking on real hardware. It runs the same sizing and placement functions the viewer uses,
once per screen, and writes <smokeDir>\monitor-refit.txt. On the development machine (single
3072x1920 @200%):

monitors=1
primary=\\.\DISPLAY1

[0] \\.\DISPLAY1 primary=True
    boundsPx=(0,0,3072,1920) workPx=(0,0,3072,1920) scale=2 workDip=1536x960
    image 4289x631 @0.8 -> 1228.8x180.8 dip = 2458x362 px
    window 2600x1400 dip -> clamped 1536x960 dip = 3072x1920 px
    placement from (1843,960,768,384) -> (0,0) inside=True

Every screen gets a block like that; the only thing to check is inside=True. The full recipe
(including how to read the placement log of /test-preview-diag) is in
docs/research-mixed-dpi.md.

The package usage note is Readme.txt now

Every other file in the extracted package has a Latin name — QuickLook-Next.exe,
Translations.config, lib\, runtimes\, QuickLook.Plugin\ — and the one Chinese filename stood
out in the listing and was awkward to type in a shell. The content is unchanged: how to start it,
the .NET runtime requirement, how updates work, where the data and logs live, and the optional
switches.

Verification

• Unit tests 94/94 (four new placement cases).
• Single-screen baseline unchanged: the 6000x4000 image still lands at
  1154x770 DIP / 2308x1540 px @(382,190), pixel for pixel with the 5.0.10 record — this was an
  equivalent refactor, not a behaviour change.
• The packaged build itself ran /test-monitor-refit and image/PDF/Markdown previews with an empty
  log; the in-package version reads 5.5.0 and the root contains Readme.txt.
• Known limitation: the real mixed-DPI behaviour still needs a multi-screen machine (use the switch
  above); one screen cannot reproduce it.

Upgrading

Version 5.5.0. Behaviour is identical to 5.4.0 (low memory mode, plugin search, OCR and the
accessibility work are unchanged) — this release is about verifiability and packaging consistency.
Automatic update installs straight over the top.