Merge fix/c3-client-versions: CLI-46 client versions bumped past the published train (0.2.1 / Java 0.2.2), pypi 0.2.0 broken-connect() note, check-client-versions.ps1 drift guard in CI

docs/ClientPackaging.md

@@ -72,6 +72,23 @@ carries the equivalent guard for the Go module: it refuses to create a
 `ClientVersion` already equals `X.Y.Z` (CLI-21/CLI-39), so a forgotten
 version bump fails the tag instead of shipping a mismatched module.
 
+Both of those guards only fire when someone actually runs a publish.
+CLI-46 found the same hazard recurring silently *between* publishes: a
+real bug fix (the pypi 0.2.0 `connect()` fix above, commit `a8f86b5`) plus
+later wire-surface changes shipped into the tree while every version
+constant still read the already-published number, and nothing recorded
+that the registry artifact and the in-repo source had diverged.
+`scripts/check-client-versions.ps1` is the PR-time half of that guard —
+wired into CI (`.gitea/workflows/ci.yml`, the `portable` job, next to the
+codegen freshness checks): for each client it finds the latest publish tag
+(`clients/go/vX.Y.Z` for Go — the only client with a git tag at all; .NET,
+Python, Rust, and Java publish straight to a package registry via
+`pack-clients.ps1 -Publish` with no corresponding git tag, so the check
+reports "no tags found" and passes for those four today) and fails if
+`clients/<lang>` differs from that tag while the version constant still
+equals the tag's version. A client with no publish tag is not a
+violation — there is no "since the last publish" window to check yet.
+
 As of 2026-08-07 (CLI-39) all five clients — plus `ZB.MOM.WW.MxGateway.Contracts`,
 which releases in lockstep with the .NET Client — moved to **0.2.0**,
 converging on one number after four of the five had drifted onto the
@@ -111,6 +128,26 @@ confirmed present through the Gitea package API after the push, and
 `go list -m` resolves the Go tag. These are the numbers a future release
 bumps off.
 
+**The published pypi `0.2.0` artifact has a broken `connect()` (CLI-46).**
+Its `connect()` built the `grpc.aio` channel inside `asyncio.to_thread`, and
+a `grpc.aio` channel binds to the event loop current on the *constructing*
+thread, so every non-stub connection raised `RuntimeError: There is no
+current event loop in thread` — TST-24's first real-wire run caught it.
+Fixed in-tree by commit `a8f86b5` (2026-08-10): `resolve_channel_security`
+now runs off-loop, `create_channel` runs on-loop. That fix, plus later
+wire-surface additions (`d9ea8a8`, `c748361`), shipped after the 2026-08-07
+publish while the version constants still read the already-published
+0.2.0/0.2.1 numbers above — see `clients/python/README.md` for the
+user-facing warning. **0.2.0 is superseded by 0.2.1; do not install it.**
+
+As of this remediation (CLI-46), the in-source version constants for the
+.NET, Go, Python, and Rust clients (plus Contracts) read **0.2.1**, and the
+Java client reads **0.2.2**. These are not yet published — the numbers
+above (0.2.0 four clients + Contracts, 0.2.1 Java) remain the live registry
+state until the next `pack-clients.ps1` / `tag-go-module.ps1` run. Once that
+publish lands, update this section with the new coordinates and commit(s),
+the same way the 2026-08-07 record above was written after the fact.
+
 ## .NET
 
 The .NET client uses .NET 10 and references