[kvlonge]

Why

Column lineage says which columns an output reads and how, but not where the output is defined in the SQL. A UI cannot highlight the expression behind a traced column. Stars also had no source range, so findings falling back to a star had none.

Changes

• Star.span is a SourceSpan, as on other located nodes: located parses record it (not yet SQLite or SQL Server), equality ignores it, and serialised trees omit it when absent.
• Scope findings that fall back to the first located column, name or star now point at that star instead of offset 0. Three expectations move: a star modifier naming an unknown column, a USING key one side lacks, and a duplicate CTE name in a query projecting a star.
• OutputLineage::expression_range: Option<Range<usize>> is the UTF-8 byte range, in the analysed SQL, of the projection item that defines the column. A column a star brings points at the star; one a REPLACE gives a value points at that value, or at the star when the value has no range; outputs of any set operation (UNION, INTERSECT, EXCEPT, BY NAME) have none, and PIVOT pass-through columns carry no inner range (untested guard: no input reached it).
• Spans count Unicode characters. In ASCII SQL they already are byte offsets; otherwise one pass over the statement converts them, stopping at the last offset needed.

Verification

• New lineage cases slice the SQL by each range and compare the text: aliased and bare items after multi-byte text, a star over a CTE, a star with EXCLUDE and RENAME, a DuckDB REPLACE value, and UNION, EXCEPT and BY NAME outputs; the EXCEPT case fails without the third commit.
• cargo test for every syntax crate, sqlquack-parse, sqlquack-lint and sqlquack-semantics passes.
• make instruction-counts: analysis 241.3M against the 239.7M baseline (+0.7%), parse unchanged. Scanning every statement had cost +6.5%.
• cargo fmt --check, both make rust-lint clippy passes on the touched crates, and fensu check pass.