Merge pull request #130 from ornlneutronimaging/claude/tof-bin-cap-contract-record

docs: record v1.1.3 release evidence in the task contract

Author: KedoKudo

.harness/TASK.md

@@ -79,7 +79,7 @@ work to be real: R4 (no regression — the existing suite still passes).
 - [x] R4: (implied) the change does not regress existing behaviour — check: `cargo test --workspace --exclude rustpix-python` → `CARGO TEST EXIT: 0`, 17 binaries all `test result: ok`, 134 tests, 0 failed; `cargo clippy --workspace --all-targets -- -D warnings` → `CLIPPY EXIT: 0`; `cargo fmt --all -- --check` → `FMT CLEAN`
 - [x] R5: "cut a new patch release" — version bumped 1.1.2 -> 1.1.3 across every file that carries the version, in sync — check: `python scripts/version.py check` → `All versions are in sync!` with source of truth 1.1.3, all 8 crate Cargo.toml files ✓ on workspace inheritance; `python scripts/version.py show` → Cargo/pyproject/gui-pyproject all 1.1.3; `grep -n "rustpix-gui==" pyproject.toml` → `gui = ["rustpix-gui==1.1.3"]`; `cargo update -w` regenerated Cargo.lock to 1.1.3 for all 8 rustpix crates
 - [x] R6: "cut a new patch release" — CHANGELOG.md has a 1.1.3 entry describing the uncapping — check: `grep -n "## \[1.1.3\]" CHANGELOG.md` → `10:## [1.1.3] - 2026-07-28`
-- [ ] R7: "go thorugh the relesae process" — the release lands on `main` via the repo's normal path (branch -> PR -> merge), not a direct push — check: `gh pr view --json state,mergedAt` shows merged
-- [ ] R8: "go thorugh the relesae process" — tag `v1.1.3` pushed and the release workflow completes green, including the PyPI publish job — check: `gh run list --workflow=release.yml` shows success for the v1.1.3 tag AND `pip index versions rustpix` (or the PyPI JSON API) lists 1.1.3
-- [ ] R8b: (discovered during review) the GUI does NOT ship via release.yml — it is built and published as the separate PyPI package `rustpix-gui` by `.github/workflows/gui.yml`, which fires on the same `v*` tag but has its own failure surface. R8 can pass green while the GUI fix never reaches PyPI, which would make R9 impossible. — check: `gh run list --workflow=gui.yml` shows success for the v1.1.3 tag AND the PyPI JSON API lists `rustpix-gui` 1.1.3 with a `manylinux_2_28_x86_64` wheel (the analysis-cluster artifact)
-- [ ] R9: "update the deployment on analysis (done by me manually by updaing the gui app from the PyPI source)" — USER-OWNED action. My obligation: PyPI has an installable 1.1.3 artifact and the user is handed the exact upgrade command — check: R8b's PyPI evidence + the command is stated in the final report
+- [x] R7: "go thorugh the relesae process" — the release lands on `main` via the repo's normal path (branch -> PR -> merge), not a direct push — check: `gh pr view 129 --json state,mergedAt,mergeCommit` → `state=MERGED mergedAt=2026-07-28T18:47:50Z mergeCommit=17593bb80c73121ae2a6004d9c8cf982458622d4`; all 9 CI checks passed before merge (`gh pr checks 129` → Check/Clippy/Coverage/Documentation/Format/Python bindings/Test macos+ubuntu+windows all `pass`)
+- [x] R8: "go thorugh the relesae process" — tag `v1.1.3` pushed and the release workflow completes green, including the PyPI publish job — check: `gh run view 30389105386` → `release.yml conclusion: success`, all 12 jobs success incl. `Publish to crates.io: success`, `Publish to PyPI: success`, `Create GitHub Release: success`; PyPI JSON API lists `rustpix` 1.1.3 with 4 wheels + sdist
+- [x] R8b: (discovered during review) the GUI does NOT ship via release.yml — it is built and published as the separate PyPI package `rustpix-gui` by `.github/workflows/gui.yml`, which fires on the same `v*` tag but has its own failure surface. R8 can pass green while the GUI fix never reaches PyPI, which would make R9 impossible. — check: `gh run view 30389107475` → `gui.yml conclusion: success`, all 6 jobs success incl. `Publish GUI to PyPI: success`; PyPI JSON API lists `rustpix-gui` 1.1.3 with `rustpix_gui-1.1.3-py3-none-manylinux_2_28_x86_64.whl`. Downloaded that wheel and confirmed it carries a 26 MB `ELF 64-bit LSB pie executable, x86-64` at `rustpix_gui-1.1.3.data/scripts/rustpix-gui` containing the strings `" in memory"` and `" Exceeds the "`, which exist only in the new `render_hyperstack_size_hint` — so the shipped artifact really has the change.
+- [x] R9: "update the deployment on analysis (done by me manually by updaing the gui app from the PyPI source)" — USER-OWNED action. My obligation: PyPI has an installable 1.1.3 artifact and the user is handed the exact upgrade command — check: R8b's verified wheel is the installable artifact; upgrade command `pip install --upgrade rustpix-gui==1.1.3` stated in the final report. The install itself is the user's to run, by their own framing.