fix: two column lineage correctness bugs (nondeterministic ordering, fabricated origins)

[eitsupi]

Note

This change was written by Claude Code and Codex under my review and direction.
I have verified the diff, run the test suite, and confirmed
the behavior change against a probe crate. Please review it as you would any other
patch. Happy to split this into two PRs if you prefer one fix per PR — the two
commits are independent and can be cherry-picked separately.

Two independent column lineage correctness bugs, one commit each, both against the 0.2.0 public API (no type or signature changes).

1. Nondeterministic column mapping order (56677a0)

resolve iterated final_ids as a HashSet, so the order of the resulting
ColumnMappings varied between runs. The later sort_by_key keys on the output
column name, so it does not stabilize outputs that share a name:

SELECT a.id, b.id FROM a JOIN b ON a.id = b.bid

Here both mappings target id, and which one came first was decided by hash
iteration order. Callers that match mappings positionally saw them swap.

The fix walks the scope's ordered_cols, which already carries projection order,
instead of collecting into a set first. Verified by re-running the new test 12 times
against the unfixed resolver (12/12 failures) and 50 times against the fixed one
(stable).

2. Fabricated column origins for unresolved columns (e8e4790)

When a column could not be resolved, the resolver returned a fully resolved
ColumnOrigin::Concrete carrying an invented table name:

• ?unknown? when no binding was visible in scope
• ?cte? when the target CTE or derived table had no output column of that name

SELECT bare_col
-- before: bare_col <- ?unknown?.bare_col   (Concrete)

WITH cte AS (SELECT present FROM source) SELECT missing FROM cte
-- before: missing <- ?cte?.missing         (Concrete)

Concrete means "this column comes from this table". These origins violated that
contract, and a consumer had no way to tell fabricated lineage from real lineage
short of string-matching the sentinel table names. For a lineage tool, a confident
wrong answer is worse than an honest unknown.

Both sites now return ColumnOrigin::Ambiguous with an empty candidates list,
which already carries the meaning "not resolved to a table; a catalog is needed".

Returning None instead was considered and rejected: collect_leaf_origins maps
None to an empty vector, so the unresolved source would silently disappear from an
otherwise valid mapping (SELECT missing + known FROM t would keep only known),
and an empty sources list already has a legitimate meaning for constant
expressions.

apply_catalog guard

This part is load-bearing rather than incidental. apply_catalog rewrote every
Ambiguous into Concrete whenever CatalogProvider::resolve_column returned
Some. Without a guard, a provider that resolves a column by name alone would turn
the new empty-candidate Ambiguous straight back into fabricated Concrete
lineage, undoing the fix. apply_catalog now attempts catalog refinement only for
non-empty candidate sets.

The cost is that a catalog can no longer do a global by-name lookup for a column
with no query-visible table. That seems right: a column existing somewhere in the
catalog is not evidence that its table participates in this query, and in the
missing-CTE-column case it is especially likely to be wrong. This boundary is now
pinned from both sides by tests — genuine ambiguity is still resolved by a catalog,
an unresolved origin is not.

ColumnOrigin::Ambiguous and CatalogProvider::resolve_column are documented
accordingly, and the Python stub notes that candidates may be empty.

Compatibility

No public type, variant, or signature changes, so this fits a 0.2.x patch release.
Observable results do change for previously unresolved columns: a Concrete with a
sentinel table becomes an Ambiguous with no candidates, and the CLI prints ?x?
where it printed ?unknown?.x. That is the point of the fix, but if you would
rather ship it as 0.3.0 that is entirely reasonable.

Tests

93 pass (was 90). New:

• unresolved_column_has_empty_ambiguous_candidates
• missing_column_from_cte_has_empty_ambiguous_candidates
• catalog_does_not_fabricate_unresolved_column_owner
• two tests covering deterministic ordering with duplicate output names

cargo clippy --all-targets reports one unneeded_struct_pattern warning in
build/statement.rs, which is pre-existing on main and untouched here.

cargo fmt was deliberately not run: main is not rustfmt-clean, and running it
would bury these changes in unrelated reformatting.