fix(release): pin desktop PR operations to block/buzz

[wesbillman]

Summary

Pin every GitHub CLI PR operation in the Desktop release helper to block/buzz.

Without an explicit repository, gh refuses to create the release PR in checkouts that have multiple GitHub remotes and no configured default. This happens after the candidate has already been generated, validated, committed, and pushed.

Add release-contract assertions covering the list, edit, and create paths so repository qualification cannot regress.

Validation

• bash -n scripts/prepare-desktop-release.sh scripts/test-release-ref-contract.sh
• scripts/test-release-ref-contract.sh
• pre-push branch-skew

[wesbillman]

Independent review by Carl on Wes’s behalf at exact head 7ebc13969c1e8760c42c367c483a66bc37985a2a: clear. The fix is correct, minimal, and safe; no blocker found.

I reproduced the precondition in the review checkout: it has origin plus contributor, and gh repo set-default --view reports that no default repository is configured. Unqualified gh pr ... is therefore ambiguous exactly as described. Adding --repo block/buzz to list, edit, and create pins both read and write operations to the canonical repository and removes ambient remote/default-repo dependence. The option placement is valid for all three gh commands.

The three call sites are the complete PR-operation surface in prepare-desktop-release.sh; candidate generation/validation was already explicitly pinned to block/buzz. Branch creation, force-with-lease semantics, candidate SHA/tag binding, PR body, and release authorization are unchanged. This also fails safer than ambient inference: it cannot accidentally find/edit/create the release PR in a contributor fork merely because that remote became GitHub CLI’s default.

Validation at this exact head: bash -n passed for both scripts; scripts/test-release-ref-contract.sh passed including its signed-canary/cache subcontracts; git diff --check passed; worktree clean; remote head unchanged. I also confirmed current main merges without a reported conflict.

The added assertions are static contract guards rather than a mocked end-to-end gh execution. That matches the existing test’s style and adequately pins this three-token regression, though a future release-script test harness could stub gh if this script accumulates more behavior. Not a reason to delay this fix.

Operational note: this is not required to unblock the release already in progress because the documented two-command workaround exists. Merge after exact-head CI is green; it prevents the next release from reaching the final PR step and falling into the same stupid little pit.