add generated upgrade test harness

[aagbsn]

This implements a test harness to verify clickhouse upgrades for our database schema. #437

[hellais]

We should also read the changelog for any potential tricky breaking changes and ideally run the target version with the API + data pipeline to make sure that it's able to work without any problems.

Scrolling through the changelog for "backward incompatible change" here are some highlights worth being careful of:

Downgrading after upgrading may cause data loss. Propagate data types serialization versions to nested data types
https://clickhouse.com/docs/resources/changelogs/oss/2026#263-backward-incompatible-change

So we need to be extra careful once we go past 26.3 (maybe we should stop 1 LTS behind until we have done thorough testing).

Especially tricky are ones where they say things like:

Renamed functions searchAny and searchAll to hasAnyTokens and hasAllTokens for better consistency with existing function hasToken
https://clickhouse.com/docs/resources/changelogs/oss/2025#2510

Which means that we need to make sure that we aren't using these functions, otherwise they will crash at runtime.

Disallow truncating replicated databases
https://clickhouse.com/docs/resources/changelogs/oss/2025#backward-incompatible-change-10

Might apply to us in the data pipeline

It might also be worth passing the whole changelog history into an llm and give it our codebase to hunt for potential breakages.

In any case I would suggest for sure upgrading to strictly less than 26.3, since if we mess that upgrade path up, we have no way to rollback.