upstream-sync: adopt our own PR, and open the home-manager one

[Andrew Gazelka (andrewgazelka)]

Opening the first PR through this machinery found a bug in it, and reviewing home-manager for the opt-in gate found four things in our patch.

The tool called its own new PR someone else's duplicate

upstream-pr --open run by hand opens the PR without going through the sync loop, so the status file never learns of it. On the next upstream-sync the fuzzy duplicate search found that very PR, reported it as a competitor, and left pr: null with the patch recorded as blocked by itself.

"Have we already sent this?" and "did someone else propose this?" are different questions. The first is now asked directly, before the search, with gh pr list --head <branch> on our own branch. The head repo owner is checked in the tool, because gh pr list --head matches on the bare branch name and silently returns nothing for owner:branch; without the owner check a stranger's same-named branch would be adopted as ours. The live failure is pinned as a regression test.

home-manager is opted in, and this change is the review that earned it

The gate said "out pending review: nobody has checked our commits against their conventions". Doing that check found:

• Subject was 61 characters against their documented 50, and five body lines exceeded 72. Fixed in the fork, message only, tree byte-identical. The intent key follows the commit subject, so it moved with it.
• A Refs indexable-inc/index#3689 trailer pointing at a repo their reviewers cannot open. Dropped; that context is in the registry now.
• Their treefmt reports both changed files clean, and tests/modules/files passes on the patched tree, target-conflict included, which is the collision path this patch rewrites.
• Our base was 45 commits behind master and both files we touch had moved, so the first submission conflicted and their CI failed on it. Rebasing produced one conflict, and resolving it took upstream's own fix (deeb6b7e, unintended subshell expansion in a backup message) into the block our patch had moved into a function. We would otherwise have reintroduced that bug.

Result

nix-community/home-manager#9718 is open and not a draft, with all seven of their checks green.

Known gap: the fork's ix-patched branch still sits on the old base, so it and the PR have diverged. Rebasing the maintained branch changes what workstation configs consuming it get, so it is a deliberate act rather than something to slip into this change.

Assisted-by: Claude Opus 4.5 via Claude Code

Note

Adopt existing fork PRs in upstream-sync instead of treating them as duplicates

• Adds gh::find_ours in gh.rs to query GitHub for open PRs whose head branch and owner match our fork, returning the newest match as a tracked Pr.
• Updates handle_patch in main.rs to call find_ours before the duplicate check; if a matching PR is found, it is adopted and refreshed rather than left with pr: null.
• Enables autoContribute in fork-packages.nix and renames the patch key to "files: batch link creation and target checks" (shortened subject).
• Records live state for the home-manager PR #9718 in home-manager.json.
• Behavioral Change: consumers referencing the old patch key "files: batch symlink creation and target checks in activation" must update to the shortened key.

^{Macroscope summarized de3f4cb.}

[github-actions]

Required workers must start within 120 minutes after GitHub marks them ready. Once assigned, each has 120 seconds for setup, then 2400 seconds for validation, then 10 seconds for cleanup. Add the ci/big-change label and then re-run the whole workflow for extended validation; a --failed re-run reuses the budget this comment describes. Lockfile and Rust toolchain changes are labeled automatically.

Routine validation applies.