sql_check keys is O(|L| x |R|) per probe and reports "unmatched keys found" for any key subset #1491

Problem

sql_check in keys mode can run for minutes on large tables and then reports "unmatched keys found" even when every left key matches a right key.

Mechanism

• checkKeys (packages/opencode/src/altimate/tools/sql-check.ts:314-347) computes count(...) and exists(...) as correlated EXISTS over l x r with functions applied to both sides (LOWER(TRIM()), regexp_replace, a leading-zero CASE). The prefix_suffix probe is a non-equi SUBSTR comparison. None can use a hash join, so each probe is |L| x |R|.
• The verdict (sql-check.ts:382) says "unmatched keys found" unless matched_exact equals both distinct counts, so a lookup of keys into a larger dimension table always "fails". Integer IDs also trigger a spurious prefix/suffix difference, because 12 is a prefix of 123.

Evidence

• 119 recorded keys checks; 32 took over 30 s (3,170 s total, 10 sessions); one took 360 s with nothing else running. Size: 6,696 left keys x 127,600 right keys, about 854M pairs times seven probes.
• 71 of 87 "unmatched keys found" verdicts had every left key matched exactly; 53 of those also flagged a spurious prefix/suffix difference.

Impact

Time (consumes budget in sessions using gpt-5.6-sol) and a misleading verdict.

Proposed fix

• Compute the normalised forms once per side in CTEs and match with equality joins.
• Run the prefix/suffix probe on a bounded sample, or only over unmatched keys.
• Report left coverage ("left subset of right: 6,696/6,696") separately from right coverage and word the verdict accordingly.
• Skip text-format probes when both columns are integer-typed.

Acceptance check

• 7k x 130k distinct keys finish in under 5 s.
• Left keys fully contained in a larger right set yield a verdict that says left coverage is complete.
• Integer keys do not produce prefix/suffix findings.