QuickLook-Next 5.1.0

OCR: mixed-language images no longer lose whole lines

5.0.11 let OCR pick its own language engine, but that was one engine per page: on a page that
has both Chinese and English, the engine with the better overall score won the whole page and the
other language's lines were dropped entirely. Measured on a small bilingual screenshot (English
heading + invoice line + Chinese contact line):

	result
before	2 English lines, 67 characters, the Chinese line gone (even though the Chinese engine had read it)
after	all 3 lines, 89 characters, the Chinese one being "联系人：张三电话 13800001111"

The rule is now per-line merging: the lines each engine reports are grouped by vertical position
(two boxes overlapping by more than half of the shorter one are the same line), each group keeps the
text that scored best inside it, and the groups are emitted top to bottom. A line that several
engines read appears once, and two stacked lines are never merged just because they are close.

OCR: small images are enlarged before recognition

The engine reads small text badly, and CJK worst of all. Measured on a 560×150 screenshot with 14 px
text:

	Chinese line
as-is	联系人：张三电沽 138 佣佣 1 1 1 1
enlarged 2×	联系人：张三电话 13800001111 (identical to the same text rendered at 28 px)

So a picture whose longest side is under 1000 px is enlarged twice before recognition (still
inside the engine's per-side limit and the 16 MP cap); larger pictures are left alone — the
1264×1522 page from the report already reads well and scaling it would only cost time. Recognition
time is unchanged in practice: 1.06 s for the small image and 1.17 s for that page, app start
included.

Fixed: a preview request from Explorer could be dropped silently

The pipe server accepts one connection at a time and there is a real gap between two of them.
Forwarding a preview request used to try once (2 s timeout): hitting the gap meant nothing
happened at all — "I double-clicked and nothing came up" — and the second instance then decided it
was "already running" and showed a message box, for a perfectly valid path (roughly one in three in
automated runs). It now retries four times, 600 ms each (~3 s total), falls back to the message
box only when the running instance is genuinely stuck, and writes the failure to the log.

Fixed: the shipping build was still writing test diagnostics

The preview warm-up wrote warmup.txt into the temp folder on every start — its guard asked "is a
test directory set?", and that value is always true (the same trap as the update prompt fixed in
5.0.11). It is now written only with /test-warmup, and the smoke test passes that switch.

Improved: the log stops growing forever, and data & cache can clear it

• Rotation: past 1 MB the diagnostic log moves to QuickLookNext.Exception.log.1 (one previous
  file is kept), so the log always holds "this session + the previous one". Measured: after
  injecting 1,064,420 bytes the next write moved the whole file aside and started a 1,296-byte one.
• Clear log: a new button in the data & cache panel (the log is data, so it is not deleted by
  "clear cache"); a file in use reports "try again later" instead of failing, and the numbers
  refresh immediately. The strings exist in English, Simplified and Traditional Chinese.

Verification

• Unit tests 78/78 (nine new: per-line merging 4, small-image upscaling 2, log clearing and
  rotation 3).
• End to end: the bilingual screenshot (all 3 lines), the Chinese page from the report (317
  characters, character-perfect), an English test image (word-perfect).
• The packaged build itself re-ran the bilingual image with the same result; in-package version
  5.1.0.

Upgrading

Version 5.1.0. Worth taking: screenshots that mix Chinese and English used to lose lines, and
small-text screenshots recognise Chinese noticeably better now. Automatic update installs straight
over the top.