fix: an ambiguous join is refused instead of guessed

[kiyeonjeon21]

Why

ensureJoin matched on the table pair rather than the column, so a table with two foreign keys into the same target - billing_region_id and shipping_region_id both into regions - silently joined on whichever edge sorted first.

That is the worst shape of bug this engine can have: the answer looks perfectly ordinary while answering a question the user never asked.

Reproduced on a fixture where both edges are inferred at 93%:

before:  OK -> ... JOIN "regions" ON "orders"."billing_region_id" = "regions"."id" ...
after:   REFUSED -> Cannot use "tier": orders joins regions through more than one key
         (orders.billing_region_id or orders.shipping_region_id), so this grouping is
         ambiguous. Write the SQL directly and pick the one you mean.

What

It refuses and names both candidate keys, so the agent can write the SQL it actually means. That matches how the compiler already handles fan-out and unknown metrics: refuse rather than guess.

Verification

• npm run check exit 0; npm run test:cli 148 pass / 0 fail
• npm run eval:engine 18/18 and eval:engine:hard 25/25, both unchanged
• A regression test pins the fixture and asserts the refusal names both columns

Worth noting how this one was found: by reading the code path, not by measurement. Neither committed dataset can trigger it through query_metric, because a lookup table's label is never a groupable dimension - so the eval was structurally blind to it. A useful reminder that a scoreboard only covers what its cases can reach.

This closes the engine-defect list the hard dataset opened (ROADMAP step 6).

🤖 Generated with Claude Code

https://claude.ai/code/session_01CKZ9UVgw2Mhiu6T5YAG7k6