Upgrade `gh` to >= 2.73.0 on every box — below it you cannot read a PR in the terminal nf-dxt ← Beads

Twinned from https://github.com/cfsh/ninefold/issues/742 by tools/beads/import_github.py's reconcile pass.

gh on every box needs to reach 2.73.0 or newer. Below that, three ordinary commands fail against this repo.

⚠️ Corrected 2026-08-07: this opened by saying #735 makes presubmit.py --doctor report that as a required line. It does not — the check was removed from #735 entirely and parked here, because every box is below the floor and CLAUDE.md makes --doctor the session-start check whose non-✓ answer is *"stop before you touch anything"*. Adding it ahead of the upgrade would halt every session on every box. Adding it is step 2 of this issue, after the boxes are up — see the parking comment below for what to lift and from which commit.

@aedanpope's call, in chat: upgrade the boxes, put it in --doctor, and add it to the CTO's new-machine checklist. #735 does the second; cfsh/nf-office covers the third. This issue is the first — the actual per-box upgrade.

What breaks below 2.73.0

| command | < 2.73.0 | ≥ 2.73.0 | |---|---|---| | gh pr edit <n> … — any flag, any PR | ✗ | ✓ | | gh pr view <n> | ✗ | ✓ | | gh issue view <n> | ✗ | ✓ | | gh pr view --json …, pr list, issue list, pr diff, pr checks, pr status | ✓ | ✓ |

``` GraphQL: Projects (classic) is being deprecated in favor of the new Projects experience, … (repository.pullRequest.projectCards) ```

⚠️ #657 concluded "only gh pr edit", and that is too narrow. It held for every path its six corroborations tested, because all of them read through --json, which gh builds differently. The bare gh pr view <n> / gh issue view <n> that a human types is broken too. So on an un-upgraded box you cannot read a PR or an issue in the terminal at all — which is a good deal more ordinary than editing one, and is why this is worth doing rather than merely worth noting.

Boundary bisected on nf-dev-sg by downloading each release and running a real gh pr edit: 2.45.0 ✗ · 2.63.2 ✗ · 2.68.0 ✗ · 2.72.0 ✗ · 2.73.0 ✓ · 2.76.0 ✓ · 2.80.0 ✓ · 2.97.0 ✓ — matching cli/cli#10942, *"Feature detect v1 projects on pr edit"*, first released in v2.73.0.

Why it is not one apt upgrade

``` $ apt-cache policy gh Installed: 2.45.0-1ubuntu0.3 Candidate: 2.45.0-1ubuntu0.3 2.45.0-1ubuntu0.3 noble-updates/universe 2.45.0-1build1 noble/universe ```

Ubuntu noble's universe has nothing newer than 2.45.0. It needs GitHub's own apt repo, per box:

```bash (type -p wget >/dev/null || sudo apt install wget -y) \ && sudo mkdir -p -m 755 /etc/apt/keyrings \ && wget -qO- https://cli.github.com/packages/githubcli-archive-keyring.gpg \ | sudo tee /etc/apt/keyrings/githubcli-archive-keyring.gpg > /dev/null \ && sudo chmod go+r /etc/apt/keyrings/githubcli-archive-keyring.gpg \ && echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" \ | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \ && sudo apt update && sudo apt install gh -y ```

The boxes

Four postures per notes/machines.md, provisioned at different times, so each needs checking separately — gh --version first, and only upgrade what is below the floor.

• [x] Linux VM nf-dev-sg (the gating host) — DONE 2026-08-08: 2.45.0 → 2.97.0, verified (#759). Version re-checked on the box first rather than taken from this issue.
• [ ] WSL office box (Ubuntu 26.04) — version unknown to me; 26.04's universe may already be past the floor, in which case nothing to do.
• [ ] Sandboxed Windows box — winget upgrade GitHub.cli, not apt.
• [ ] Aedan's workstation — his machine, his call.
• [x] bork's reviewer clone — same box, so its gh moved with nf-dev-sg's. Dispatcher not disturbed: it ticked normally at 02:32 UTC on 2.97.0 and reviewed #759 itself.

⚠️ The risk, stated plainly — this is why I did not just do it

2.45.0 → 2.97.0 is about two and a half years of gh, and nflib parses gh JSON throughout (Gh.pr_view, pr_list, pr_files, api). A changed field or output shape would surface as a tooling failure, not a gh failure.

I spot-checked the read paths our tooling actually uses on 2.97.0 against 2.45.0 and found no differences — but that is a spot check, not a proof, and it was done on one box with several sessions live on it. The right shape for this work is:

1. gh --version on each box first; skip any already at the floor.
2. Upgrade on a quiet box, or at a moment no session is mid-merge.
3. Then ./presubmit.py --all and ./presubmit.py --doctor, and a real merge_pr.py --why <n> + poll.py --check, before calling it done.
4. Roll back with apt install gh=2.45.0-1ubuntu0.3 if anything moves.

Whoever takes this should own the verification, not just the install — the failure mode of a bad gh upgrade is the same class #657 is about: tooling that reports something other than what happened.

Not covered here

The *code* fix is done and independent — #735 routes Gh.retarget/request_review/set_labels through REST, so the tier is correct on 2.45.0 either way. Nothing is blocked on this issue; it buys back the hand-typed commands and gets the boxes off a gh that is quietly rotting as GitHub retires more of Projects (classic).

Refs #657. Filed unclaimed.