Both packages take a patch. Neither adds, removes or changes public API, and
neither changes a number: estimates, standard errors, variances and degrees of
freedom are bit-for-bit identical to 0.22.0 across stratified/clustered,
stratified-only, PSU-only and unstratified designs, with and without where=
zero weights, and identical at 1, 2 and 10 rayon threads. Two perf changes ship:

  - svy-rs stops indexing the Taylor design twice per estimate and overlaps
    the design build with the score pass (#114)
  - the Python prep layer stops paying O(B^2) column lookups in the replicate
    count (#113)

A patch on svy-rs is safe here for the reason 0.11.1 was not. svy 0.22.0 pins
svy-rs>=0.12.0,<0.13.0, so a 0.12.1 reaches every existing install on the next
sync — which is exactly why b356d59 refused a patch when the change moved
domain df, by= confidence intervals and deff. This change moves nothing; a
patch delivers a pure speedup to installs that already permit it.

svy's own pin floor moves to >=0.12.1 so a 0.22.1 install cannot resolve an
extension older than the one it was built and verified against. Note this does
not gate the extension change behind an svy upgrade and is not meant to:
0.22.0's published range already admits 0.12.1, and no metadata in 0.22.1 can
retract that. Gating would have required svy-rs 0.13.0.

Six version strings move, not four. Both svy-rs strings (Cargo.toml for the
crate, pyproject.toml for the distribution maturin reads — bumping only the
former leaves the version the pin resolves against untouched), svy's
pyproject.toml, and __version__ in svy/__init__.py, which uv build does not
touch and which still said 0.21.1 after the 0.22.0 bump. Cargo.lock and uv.lock
carry the workspace member versions; uv.lock was edited to those two lines
rather than regenerated, because a local `uv lock` also rewrote unrelated
python_full_version markers on ipython's dependencies.