Cut 0.5.191 — paired with CIRISServer 0.5.191, and keep the five-wheel matrix

[emooreatx]

Cut 0.5.191 — paired with CIRISServer 0.5.191

CIRISServer 0.5.191 is prepared and pinned to ciris-client==0.5.191
(CIRISAI/CIRISServer#496, addressing #495). The versions are gated to move
together, so this is a matched cut: the server side is done and waiting on yours.

Why the pairing is enforced rather than conventional

The desktop app compares its CLIENT_VERSION against the node's reported version
on the full leading semver, so a node shipping an older client greets its own
operator with "Update recommended" against the dependency it was built with. The
wheel lane that used to keep the two in step went away when client/ was deleted
(#471), and gate_client_pin_matches_this_release inherited that obligation.

What 0.5.191 needs to carry

The four changes in CIRISClient#7 — diagnostics export, the client-side wipe, the
Android testableWithHandler registerElement fix, and the desktop
PlatformLogger → DebugLogBuffer wiring. CIRISServer needs none of them
inherited: client/ was deleted in 0.5.189, so there is no vendored copy here to
drift.

The wheel matrix must keep the 0.5.190 shape

This is the one hard requirement from our side, and it is now gated.

wheel	contents	resolved by
py3-none-any	pure Python, no jar — 3.14 MiB at 0.5.190	Android, iOS, any tag you do not build for
py3-none-macosx_* / manylinux_* / win_amd64	pure Python + uber-jar	desktop, via the more specific tag

0.5.191 must publish all five. CIRISServer#493 was 0.5.189 shipping four
platform wheels and no universal one: a pip targeting Android matched no tag,
fell back to the last version that had one, and the == pin rejected it — so the
install failed outright rather than degrading.

We now have a release gate that reads the PyPI simple index for the pinned
client and refuses to tag when py3-none-any is absent. It is built with backoff
across the publish window, because the first version of that check false-failed on
0.5.190 while the universal wheel was still propagating — a snapshot taken during
upload said four files when five had been sent.

Watch the size, not just the presence. 0.5.186's py3-none-any was 63.0 MiB
because it carried the jar; 0.5.190's is 3.14 MiB. A ~63 MiB universal wheel would
pass our gate and quietly resume shipping ~70 MB of unusable desktop Java into a
~206 MiB APK — a regression wearing the shape of a fix.

Two things worth carrying from your own review rounds

Re-point CIRISClient#7 at final commits before anyone ports. Six review rounds
so far, and the churn is concentrated in exactly the code that issue asks
CIRISAgent to inherit. A port against a moving target is how the wipe's early
revisions — the ones that deleted the repository, then config/ — would reach a
second tree.

The iOS testableWithHandler twin. Switching controls to that modifier to
make them drivable removed them from the iOS automation tree, because iOS never
called registerElement either. That is worth stating in the release notes rather
than only in a commit: anyone adopting the diagnostics surface on iOS inherits
both halves of it.

Sequencing

1. CIRISClient publishes 0.5.191 with all five wheels
2. CIRISServer#496 goes green — its CI is currently and correctly red on
   "ciris-client==0.5.191 is not on the index at all", which the gate reports
   as the in-flight-pairing state rather than as a broken matrix
3. We merge and tag v0.5.191
4. CIRISAgent deletes client/ against final artifacts

Related: CIRISClient#7 · CIRISAI/CIRISServer#495 / #496 / #493 · CIRISAgent#1091