Fix parameter inference for aliased CTE columns

[riordanpawley]

Summary

Parameter inference indexed catalog tables but skipped common-table expressions. As a result, a bind parameter compared with an aliased CTE column failed compilation with column "activity_at" does not exist, even though output-column analysis had already resolved the CTE.

This change indexes the resolved CTE columns in the same parameter-inference map used for catalog tables. The end-to-end fixture is the minimal reproduction: one base column renamed in a CTE and referenced beside $1 in an aggregate FILTER.

User-facing changes

sqlc now infers parameters compared with aliased CTE columns instead of rejecting the query as an unknown column.

Existing CTE update parameters now use their resolved non-null column types instead of nullable fallback wrappers; the corresponding golden output is updated.

Validation

• Confirmed the fixture fails on unmodified main with column "activity_at" does not exist.
• go test ./internal/endtoend -run 'TestReplay/base/cte_filter_alias' -count=1
• go test ./internal/compiler ./internal/endtoend -run 'TestReplay/base/cte_filter_alias' -count=1
• Regenerated the existing cte_update fixture to record its newly inferred non-null parameter types.

Risk

Low. The new indexing path runs only when a range variable resolves as a CTE rather than a catalog table. It carries the CTE's already-resolved names and types into existing parameter inference. Callers generated from affected CTE updates may move from nullable wrappers to scalar parameters when the source columns are non-null.

[riordanpawley]

Closing as a duplicate. #4430 already fixes CTE-column lookup in parameter inference and tracks the ambiguity concern with sharing the regular-table type map; #3585 is the existing issue. I should have found those before opening this PR.