pins: upstream drift — reconverge@0.6.1 launchbound@2.2.1

[github-actions]

Upstream movement detected by the scheduled pins watch. Nothing was bumped.

• reconverge: pinned 0.5.0, crates.io has 0.6.1
• launchbound: pinned 2.1.0, crates.io has 2.2.1

cuda-oxide upstream HEAD is 6abfaa09 (informational: reconverge 0.5.0 verifies a766fc26 on nightly-2026-04-03, so HEAD is not a bump target)

The four pins (nightly nightly-2026-04-03, reconverge 0.5.0, cuda-oxide a766fc26, launchbound 2.1.0) move together or not at all, one bump per commit, no behaviour change riding along. A bump must touch, together:

• research/rust-toolchain.toml (nightly)
• the cuda-device rev in the research workspace manifests
• the pin table in ARCHITECTURE.md and CONTRIBUTING.md
• the enumerated family ban lists in deny.toml (bans are exact names)
• docs/research-baseline.md must be re-measured, not edited
• this workflow's PIN_* env block

termlens moves alone (it pairs with nothing) but still gets its own commit.

[vyncint]

Worked out what this bump actually is, so the next attempt starts from the answer rather than the question.

pins.yml derives two of the four pins from the pinned reconverge release, so bumping reconverge decides them. Read from vyncint/reconverge@v0.6.1:

• conformance/PIN → cuda-oxide 26754ae52c26c097dc1c465a1e42c4c5d05a3d40 (26754ae5)
• rust-toolchain.toml → nightly-2026-08-28

So the coordinated bump is all four, together:

pin	from	to
PIN_RECONVERGE	0.5.0	0.6.1
PIN_LAUNCHBOUND	2.1.0	2.2.1
PIN_CUDA_OXIDE	a766fc26	26754ae5
PIN_NIGHTLY	nightly-2026-04-03	nightly-2026-08-28

launchbound action SHA for v2.2.1: 7f767402b1da16a801ce2bb722d9c24bd9901621

Why this is not a version-string edit

The nightly moves nearly five months and the cuda-oxide rev moves with it. That is a toolchain migration: research/oxmera-cuda-oxide has to build and pass cargo reconverge check --strict against a different cuda-oxide API on a different rustc, and launchbound prune has to still admit all 12 candidates at both compute capabilities. Both are required checks, so a failure blocks every PR, not just this one.

Files that must move in the same commit (per this file's own policy — "the four pins move together or not at all, one bump per commit, no behaviour change riding along"):

• .github/workflows/pins.yml — the four PIN_* values
• .github/workflows/gate.yml — both cargo install --version, the reconverge-version: input, the launchbound action SHA, and toolchain:
• research/oxmera-cuda-oxide/rust-toolchain.toml and its cuda-oxide dependency rev
• docs/research-baseline.md — the recorded pairing

Recommendation

Its own PR, with the research workspace built locally against nightly-2026-08-28 first (rustup toolchain install nightly-2026-08-28 --component rustc-dev,llvm-tools,rust-src), because the likely work is fixing research/oxmera-cuda-oxide against the newer cuda-oxide — not editing the pins. Deliberately kept out of the 0.5.1 and 0.5.2 release PRs so a gate failure could not block a crate release.