Add Precise (exact) equity mode alongside Fast (Monte Carlo)

[testtest126]

Context

Follow-up to #6 (merged). Resolves an explicit ask: an optional "Precise" (exact enumeration) mode for the Equity Calculator UI, kept separate from the default Fast (Monte Carlo) path so a button tap can never hang the screen.

Correcting the premise that prompted this: the Calculate button never actually called Equity.headsUp/exact enumeration — that was already fixed before #6 merged (verified by reading the merged code directly: EquityCalculatorModel.calculate called Equity.rangeVsRange). The original UI test failures were a notation-case bug and SwiftUI Form/List lazy rendering, both fixed in #6. This PR adds the genuinely new ask — an explicit exact mode — as its own scoped feature.

What's new

• Equity.exactRangeVsRange/exactCanonicalVsCanonical — exact combo-weighted equity: enumerates every valid (non-card-overlapping) combo pair, exactly enumerates every board completion per pair via headsUp, averages equally across pairs. This is mathematically exact, not an approximation — every combo pair has the same number of board completions for a fixed board state, so uniform averaging is the true combo-weighted figure, the same quantity canonicalVsCanonical estimates by sampling. 4 new tests, including direct cross-checks against headsUp and against canonicalVsCanonical.
• EquityCalculatorView Fast/Precise toggle — Precise is disabled (with an on-screen explanation) whenever the board is empty. Exact combo-weighted enumeration preflop is (valid pairs) × 1,712,304 boards — minutes, not seconds, even for one pairing. Switching back to Preflop while Precise is selected auto-falls-back to Fast.

Bugs found and fixed while verifying end-to-end (not just "compiles")

1. Iteration count was wrong for the actual runtime environment. 50,000 iterations looked fine against this machine's swift test (macOS-native, -Onone) timings, but the iOS Simulator runs measurably slower for this CPU-bound work — 50k took 30+ seconds there, not sub-second. Corrected to 10,000 (measured, not estimated: ~10s tap-to-result end-to-end, confirmed via the UI tests). Documented the discrepancy in EQUITY.md.
2. SwiftUI's rank-selection menu doesn't show all 13 ranks without scrolling — the new UI tests only pick from the menu's initially-visible subset (A,K,Q,J,T,9-5), noted inline.
3. Stale hit-testing right after an adjacent Form row changes — tapping an element immediately after a sibling menu closes could compute an invalid off-screen hit point before layout settles ("Computed hit point {-1, -1}"). Added a tapWhenHittable helper that waits for .isHittable before tapping, used for the new board-card-picker interactions.

Testing

• swift test: 181/181 passing (177 baseline + 4 new).
• App: built clean on iOS Simulator; all 7 UI test suites pass, including 5 EquityCalculatorUITests (2 new: Precise-mode availability rules, and an end-to-end exact calculation on a flop board).

Not merging until CI is green and gates hold, per the standing auto-merge policy.