HogQL field-not-found tripwire raises a bare Exception, surfacing as a 500 with no context

Bug description

posthog/hogql/database/models.py:237 raises a bare Exception:

raise Exception(f'Field "{name}" not found on table {self.__class__.__name__}')

Exception is outside the HogQL error hierarchy, so it is not recognised as a query error and
is not translated into a 4xx. It reaches the API as a 500, and the message carries only a field
name and a table class — nothing about the query, the CTE, or the column that led there.

Why the class matters

posthog/hogql/errors.py already has the right shapes:

• BaseHogQLError (line 10)
• ExposedHogQLError (line 41)
• QueryError (line 65)

A QueryError is surfaced to the user with context. A bare Exception is an unhandled server
error, which is both the wrong status for a bad query and the wrong signal for whoever is
watching error rates.

Suggested direction

Raise a QueryError at the resolution seam where the surrounding context is still in scope,
rather than widening the exception type inside get_field itself — get_field is on a hot path
and has the least context of anywhere in the chain.

Notes

Static check on master today. Not executed.

Start with posthog/hogql/database/models.py:237 and read posthog/hogql/errors.py, especially BaseHogQLError, ExposedHogQLError, and QueryError. Trace the field-resolution seam where the surrounding query context is still available, then verify the failure is surfaced as a contextual 4xx query error rather than an unhandled 500.