SCRUM-1070-explore: propose joins from measured value overlap

[emnarahmouni-exmergo]

Closes : #220

explore relationships/explore map --infer-by-overlap (#220, depends on #208): proposes a join from measured value overlap when no column name gives inference anything to work with (acct_id_fk to ws_id, or a source that names every key id). Value overlap is strictly stronger
evidence than a name, since a name is only ever a proxy for it.

How it works

• Off by default, and named in explore map's notes even when off, so the option is discoverable without --help.
• Candidates: key-shaped columns (a proven single-column key, or a near-key whose distinct count clears the near-unique ratio, PII excluded) not already covered by a declared or name-inferred edge, paired across datasets, restricted to type-compatible pairs.
• Probed with the exact same aggregate-only overlap-probe SQL --verify already uses (authored once, transpiled per dialect); only a candidate clearing a strict containment ceiling is proposed, the rest are dropped outright.
• Bounded: the candidate pool is capped, and both the cap and how many candidates it elided are reported before anything runs, priced as a batch through the same handshake --verify uses.
• Runs after --verify on the same merged edge set, deferring entirely if verify's own checkpoint is still pending, so at most one checkpoint is ever in flight.
• A proposed edge carries a new RelationshipKind.OVERLAP_INFERRED, distinguishable from a declared or name-derived edge in both the cache and the envelope.

Bug found and fixed during manual testing

An overlap-derived edge vanished on the very next plain run, since nothing else ever rediscovers it the way a declared edge (re-read from
the dbt project every run) or a name-inferred one (re-derived from cheap metadata every run) does. Fixed by carrying a prior overlap-derived edge forward unconditionally as long as both endpoints are still known objects. That fix also closes a redundancy: a later sweep now skips a pair it already confirmed instead of re-probing (and re-paying for) it.

Verified manually end to end against a real DuckDB pair with zero naming signal: discovery, persistence across a plain re-run, and idempotency on a repeated sweep all confirmed.

explore relationships --infer-by-overlap discovers a real 1:1 join between billing_profiles.profile_ref and accounts.acct_num purely from measured value containment, the two column names share no naming convention at all. The discovered edge survives a plain re-run with no flag. This was a real bug I found and fixed during manual testing: nothing else ever rediscovers an overlap-derived edge, so without this fix it would silently vanish the moment you ran the command again without --infer-by-overlap.