Fix: validate finder pattern geometry before early termination

[bashhack]

Summary

• Add isosceles right triangle validation to HaveMultiplyConfirmedCenters() before allowing the finder pattern scanner to stop early
• When exactly 3 confirmed centers exist, compute squared distances between all pairs and reject if the two shorter sides differ by more than 40%

Context

I observed that the finder pattern scanner stops as soon as HaveMultiplyConfirmedCenters() returns true. Previously this only checked that the 3 candidates had consistent module sizes. But QR data can sometimes contain patterns that match the 1:1:3:1:1 finder pattern ratio, which is a false positive. When a false positive is accepted, the scanner stop before reaching the real third finder pattern, leading to a failed decode.

A real QR code's three finder patterns form an isosceles right triangle. A false positive from QR data produces a skewed triangle with side ratio > 1.5. The 1.4 threshold I've chosen here rejects these while still aiming to accommodate the slight asymmetry of real-world captures.

In my testing - this change has a significant impact on the observed ~5% failure rate on randomly generated TOTP QR codes at 200-400px sizes.

Testing

[x] All existing arcade/detector tests pass