sql: resolve PostgreSQL timezone abbreviations as fixed offsets

[Alignyx]

Summary

Resolve PostgreSQL timezone abbreviations such as CET as fixed-offset abbreviations when they are used by SQL timezone operations and session timezone handling.

Fixes #94078

Root cause

The affected call sites passed every timezone string to the generic timeutil.TimeZoneStringToLocation resolver. That resolver treats a name such as CET as an IANA location, so the returned location applies the region's daylight-saving rules. PostgreSQL gives abbreviations precedence through its pg_timezone_abbrevs mapping; CET therefore represents the fixed +01:00 abbreviation in the relevant conversion.

This difference is observable around daylight-saving transitions. For example, converting a timestamp through timezone('CET', ...) could produce +02:00 in CockroachDB when PostgreSQL keeps the abbreviation at +01:00. The same ambiguity affected session timezone assignment and deserialization, so fixing only the timezone() builtins would leave inconsistent behavior across entry points.

Change

Add a PostgreSQL-aware timezone resolver in pkg/util/timeutil/pgdate. It first looks up the input in the existing PostgreSQL abbreviation table and returns a time.FixedZone using that row's offset. If the input is not a PostgreSQL abbreviation, it falls back to the existing generic resolver and preserves the behavior of named IANA zones and explicit offset forms.

Use the new resolver from all identified entry points:

• the timezone() builtin overloads and timestamp construction path;
• SET TIME ZONE and session timezone mutation;
• non-local session data deserialization.

This keeps region names such as Europe/Paris on their normal daylight-saving-aware path while giving PostgreSQL abbreviations their required fixed-offset semantics.

Validation

• Exercised the reported CET conversion around a daylight-saving boundary.
• Verified session timezone assignment and deserialization use the same resolution rules.
• Ran the affected module tests, native regression checks, held-out checks, and the full regression suite.

[blathers-crl]

It looks like your PR touches production code but doesn't add or edit any test code. Did you consider adding tests to your PR?

Thank you for contributing to CockroachDB. Please ensure you have followed the guidelines for creating a PR.

Before a member of our team reviews your PR, I have some potential action items for you:

• Please ensure your git commit message contains a release note.
• When CI has completed, please ensure no errors have appeared.

I have added a few people who may be able to assist in reviewing:

• @jhatcher9999 (author of sql: timezone abbreviations should not consider daylight savings #94078)
• @rafiss (commented on sql: timezone abbreviations should not consider daylight savings #94078)

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[blathers-crl]

Thank you for updating your pull request.

Before a member of our team reviews your PR, I have some potential action items for you:

• We notice you have more than one commit in your PR. We try break logical changes into separate commits, but commits such as "fix typo" or "address review commits" should be squashed into one commit and pushed with --force
• Please ensure your git commit message contains a release note.
• When CI has completed, please ensure no errors have appeared.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}

[blathers-crl]

Thank you for updating your pull request.

My owl senses detect your PR is good for review. Please keep an eye out for any test failures in CI.

_{🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is dev-inf.}