Cherry-pick: Respect use_client_time_zone for string datetime literals parsed on the server

[zvonand]

Cherry-picked from ClickHouse#109051.

Changelog category (leave one):

• Bug Fix (user-visible misbehavior in an official stable release)

Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):

Fixed use_client_time_zone being ignored for DateTime/DateTime64 string literals interpreted on the server (asynchronous INSERT, SELECT literals). The client now propagates its local time zone as session_timezone when use_client_time_zone is enabled, so server-side parsing matches the synchronous INSERT path (ClickHouse#109051 by @groeneai).

CI/CD Options

Exclude tests:

• Fast test
• Integration Tests
• Stateless tests
• Stateful tests
• Performance tests
• All with ASAN
• All with TSAN
• All with MSAN
• All with UBSAN
• All with Coverage
• All with Aarch64
• All Regression
• Disable CI Cache

Regression jobs to run:

• Fast suites (mostly <1h)
• Aggregate Functions (2h)
• Alter (1.5h)
• Benchmark (30m)
• ClickHouse Keeper (1h)
• Iceberg (2h)
• LDAP (1h)
• Parquet (1.5h)
• RBAC (1.5h)
• SSL Server (1h)
• S3 (2h)
• S3 Export (2h)
• Swarms (30m)
• Tiered Storage (2h)

[github-actions]

Workflow [PR], commit [753e536]

[zvonand]

@blau-ai

[blau-ai]

CI triage

Verdict: 2 red checks — 0 are a real code problem in this port. 1 is a metadata/sign-off issue, 1 is an unrelated flaky test.

The PR and the S3 Fast test/Config Workflow/Finish Workflow rows are just aggregate mirrors of the two checks below — no separate failures. Everything else is skipping.

---

1. DCO — ❌ metadata, PR-related but not a code issue

All commits are incorrectly signed off … 82e5b3d "Merge pull request ClickHouse#109051 from groeneai/fix-async…" — Sign-off not found

The cherry-picked commit message has no Signed-off-by: line. This is purely a commit-metadata gate, not a build/test problem.

Fix (needs a human — I don't force-push, and this is the PR head branch, not a blau/* branch):

git checkout releasy/port/pr-109051-a7e5ac
git commit --amend --signoff --no-edit
git push --force-with-lease origin releasy/port/pr-109051-a7e5ac

(If you'd rather not amend, DCO also accepts a separate empty remediation commit — see the "add remediation commit" option in the check output. Amending the single commit is cleaner here.)

---

2. Fast test — ❌ one flaky test, not related to this PR

Failing test: 03221_merge_profile_events (result diff, not the code this PR touches):

--- reference
+++ stdout
 Vertical  1  20000  1  2  480000  1  1  1  1  1  1  1  1
-Vertical  1  20000  1  2  480000  1  1  1  1  1  1  1  1
+Vertical  1  20000  1  2  480000  1  1  1  1  1  1  0  1

The only differing column is the 12th value — ProfileEvents['UserTimeMicroseconds'] > 0. For the small 20 000-row vertical merge it returned 0, i.e. the merge was fast/idle enough that accounted user-CPU time rounded to 0. That's an inherent timing/resource-accounting flake in this test (it asserts several …Milliseconds > 0 / CPU-time counters are non-zero), and it has nothing to do with client time-zone propagation.

Evidence it isn't this PR:

• The diff only touches programs/client/Client.cpp and src/Client/ClientBase.{cpp,h} (client-side session_timezone seeding) plus a new stateless test. Nothing here influences merge profile-event accounting.
• The PR's own new test 04401_async_insert_use_client_time_zone was [ SKIPPED ] in Fast test (it's tagged no-fasttest), so the failure is definitely not from this port's additions.

Next step: safe to re-run ("Fast test" only). If it recurs, it's a pre-existing flake in 03221_merge_profile_events worth a separate timing-tolerance fix, independent of this PR.

---

Note on validation of the port itself

The new test that actually exercises this fix (04401_async_insert_use_client_time_zone) is no-fasttest, and the Stateless tests … jobs are all skipping in this run — so the port's own behavior hasn't been executed by CI yet. Once DCO is green and the Fast test re-run passes, it's worth making sure the stateless suite runs so 04401 actually validates the change.