`gh pr edit` fails repo-wide on this box, which silently breaks the documented re-request-review step nf-xrba ← Beads

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

Found while working #637 on nf-dev-probe-gate (Linux, gh 2.45.0). Filed unclaimed.

What happens

Every gh pr edit invocation against this repo fails, whatever the flag:

``` $ gh pr edit 653 --add-reviewer aedanpope GraphQL: Projects (classic) is being deprecated in favor of the new Projects experience, see: ... (repository.pullRequest.projectCards)

$ gh pr edit 653 --body-file body.md # same error ```

gh 2.45.0 unconditionally asks for projectCards in the mutation it builds for pr edit, and GitHub now hard-errors that field rather than warning. It is not specific to a flag or to a PR.

Why it matters more than it looks

CLAUDE.md documents gh pr edit <n> --add-reviewer aedanpope as the way to re-surface a PR after addressing CHANGES_REQUESTED — with the note that *"a reply alone does not resurface it"*. On this box that command has never worked, and it fails with an error about *project cards*, which reads as unrelated noise. A session that runs it, sees an error mentioning a GitHub deprecation, and moves on has left a PR sitting unrequested with its author believing it was re-requested. Silent, and it costs a review round.

Same for gh pr edit --body, which is how a PR body gets updated when scope grows — also documented ("Update the title/body when scope grows").

⚠ gh issue edit --body is not affected (the board at #398 edits fine), and gh pr create --reviewer is not affected. Only gh pr edit. That asymmetry is exactly what makes it easy to miss.

Workarounds, both verified on #653

```bash # re-request review gh api -X POST repos/cfsh/ninefold/pulls/<n>/requested_reviewers -f 'reviewers[]=aedanpope'

# update the body gh api -X PATCH repos/cfsh/ninefold/pulls/<n> -F body=@body.md ```

Worth deciding

1. Whether the fix is "upgrade gh on the dev boxes" (the deprecation is upstream-known; a newer gh drops the field) or "stop calling gh pr edit in tooling and docs". The second is robust to the box; the first is one apt upgrade and keeps the docs simple. Note the two Linux boxes and the Windows box may be on different gh versions, so an untested doc change could be wrong for one of them — gh --version on each is the first step.
2. Either way, notes/ and CLAUDE.md's re-request line need to match whatever is decided, and it would be worth a presubmit --doctor line for gh pr edit actually working, since this is the failure mode where the tool reports an error nobody connects to the thing that stopped happening.

Refs #602