Avoid LINQ allocations in OcrFixEngine.HasMostlyUppercaseLetters

[ivandrofly]

Summary

• Rewrite HasMostlyUppercaseLetters to count letters and uppercase letters in a single pass over the string instead of allocating an intermediate char[] via Where(...).ToArray() and iterating it twice
• Replace the uppercaseCount > letterCount / 2.0 double comparison with equivalent integer math (uppercaseCount * 2 > letterCount)
• Behavior is unchanged; the method is called from GetSpellCheckSuggestions for every misspelled OCR word

Benchmark

BenchmarkDotNet 0.15.8, .NET 10.0.10, Windows 11, i7-13700, ShortRun job:

Word	LINQ (before)	Single-pass (after)	Speedup	Allocated before → after
""	0.38 ns	~0 ns	—	0 → 0
123-456	22.1 ns	1.8 ns	12×	56 B → 0
hello	31.7 ns	2.8 ns	11×	96 B → 0
Hello	33.3 ns	3.7 ns	9×	96 B → 0
HELLO	32.3 ns	2.8 ns	12×	96 B → 0
L'HOMME	37.9 ns	4.2 ns	9×	96 B → 0
EXTRAORDINARY	74.5 ns	7.4 ns	10×	112 B → 0
extraordinarily	80.6 ns	8.5 ns	9×	112 B → 0

Test plan

• dotnet build SubtitleEdit.sln succeeds
• Run OCR spell check on a subtitle containing a misspelled mostly-uppercase word (e.g. HELL0) and verify the suggestion list still offers an uppercase variant first
• Verify lowercase misspelled words and non-letter tokens get the same suggestions as before (no uppercase variant inserted)

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR optimizes OcrFixEngine.HasMostlyUppercaseLetters to avoid LINQ allocations and reduce per-word overhead during OCR spell-check suggestion generation.

Changes:

• Replaced Where(...).ToArray() + Count(...) with a single-pass character scan.
• Switched the “mostly uppercase” threshold comparison from floating-point math to integer math.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[ivandrofly]

This is not fixing anything, if not making it slower, - this was my first solution but then find it was slower!

[ivandrofly]

Is * 2 confusing or?