SELECT *, <col> over a drifted union mis-assigns a value into a neighbouring column

[philcunliffe]

Found while measuring the absent-column contract for issue #778 (see PR #787). Not chased there because it sits above the dataset-wrapper layer that PR touches.

Symptom

Over a union whose partitions have drifted schemas, a star expansion combined with an explicit column mis-assigns a value into a neighbouring column:

SELECT *, git_remote FROM ai_gateway_messages

returned a row where gateway_id held git_remote's value.

Why it matters

This is a silently wrong answer, not an error: the query succeeds and the caller has no signal that a column's value came from a different column. It is the same severity class as the where-forwarding bug PR #787 fixes (a single-partition cache answered WHERE git_remote = 'zzz' with every row), but a different mechanism and a different layer.

Starting points

• The absent-column read contract is now measured and documented in llp/0240-icebird-absent-column-contract.decision.md (lands with PR Pin the icebird absent-column contract at the SQL surface (#778) #787); the value a drifted column reads is path-dependent, which is likely relevant to how star expansion builds its column list.
• hypaware-core/plugins-workspace/ai-gateway/src/dataset.js withSchemaColumns is the wrapper that declares columns; the defect appears to be in how the star is expanded and positionally mapped above it, not in the wrapper.
• test/core/ai-gateway-absent-column-sql.test.js (also from PR Pin the icebird absent-column contract at the SQL surface (#778) #787) is the closest existing harness and a reasonable model for a reproducing test.

Caution carried over from #778

The icebird mechanism in this area was described wrongly five times before #778 established it empirically. Please reproduce this against a real fixture and pin it with a test before writing down an explanation of the cause.