A duplicate output column fails with "Unable to resolve field", naming a column that exists

Bug description

A query that selects a column explicitly on top of a * that already includes it has two output
columns with the same name. Refusing that is reasonable. The problem is the message: it reports
Unable to resolve field: <that column>, naming a field that plainly exists, so the reported
cause is unrelated to the real one.

SELECT *, event FROM events

Why it is confusing

The error is raised only on the ClickHouse dialect. posthog/hogql/resolver.py:2375:

if self.dialect == "clickhouse":
    …
    raise QueryError(f"Unable to resolve field: {name}{suggestion_suffix}", node=node, fix=fix)

The other dialect branch records a non-fatal error instead. So the same query is accepted where
the HogQL dialect is used and rejected where ClickHouse SQL is printed, which makes it look
intermittent and environment-dependent rather than like a property of the query.

There is no duplicate-column detection anywhere in the resolver, so nothing ever states the
actual problem.

Suggested direction

Detect duplicate output column names at save/validate time and say so plainly, naming the
duplicated column.

Please do not make the resolver tolerate duplicate names by keeping one of the two — silently
picking a column is how the wrong column's data gets served.

Notes

Traced in the code on master today. Not executed.

Start by reading posthog/hogql/resolver.py around line 2375 and trace the save/validate path for output column names. Reproduce the SELECT *, event FROM events case, then make completion report the duplicated column plainly instead of an unresolved-field error; verify the ClickHouse dialect behavior and the existing non-ClickHouse path.