fix(ci): open a new coreutils drift PR when the previous one was closed

[chaliy]

What changed

The weekly coreutils drift run now opens a new pull request when the previous
drift PR was closed unmerged, instead of silently editing that closed PR.

The PR lookup matches open PRs only (gh pr list --head <branch> --state open)
and creates one otherwise.

Why

gh pr view <branch> resolves a pull request for that branch in any state.
Once a drift PR was closed unmerged it kept matching forever, so every later run
force-pushed chore/coreutils-args-drift, edited the closed PR, and reported
success — the drift never surfaced and no reviewer ever saw it.

PR #2161 was closed unmerged in July 2026 and has silently absorbed every drift
run since. This is not theoretical: the workflow_dispatch run today
(39019907688)
detected real drift across 20 generated files (uutils 6579cc2 → 8613dffab,
including a new EscapeSet argument to parse_escape_only and %q moving to
locale_aware_shell_escape), force-pushed it, went green — and opened nothing.

The weekly run had also been failing outright since the uucore quoting-style
rename (fixed separately in #2738), so the broken PR path was masked.

Before / After

Workflow step executed with stubbed gh/git, with only a closed PR
matching the branch:

Before — edits the closed PR; drift stays invisible:

auth setup-git
pr view chore/coreutils-args-drift --repo everruns/bashkit
pr edit chore/coreutils-args-drift --repo everruns/bashkit --title chore: sync ...

After — opens a reviewable PR:

auth setup-git
pr list --repo everruns/bashkit --head chore/coreutils-args-drift --state open --json number --jq .[0].number // empty
pr create --repo everruns/bashkit --base main --head chore/coreutils-args-drift --title chore: sync ...

When a drift PR is open, the run still updates it in place rather than opening
a duplicate (covered by a second test).

Validation:

• python3 -m unittest discover -s scripts/tests -p 'test_*.py' → 177 passed
  (174 before, +3 here). The two behavioral tests fail against the old step and
  pass against the new one.
• just check-okf → conformant.
• Workflow YAML parses.

Risk

• Low. Touches only the drift workflow's PR-lookup branch; no change to
  regeneration, the generated-only diff guardrail, or the read-only/write-scoped
  job split. Worst case is one duplicate drift PR, versus the current silent
  suppression.
• The regenerated drift this run uncovered is not included here; it ships
  separately so its printf/format changes get their own CI signal and review.

Checklist

• Tests added or updated
• Backward compatibility considered

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Workers

The latest updates on your project. Learn more about integrating Git with Workers.

Status	Name	Latest Commit	Preview URL	Updated (UTC)
✅ Deployment successful! View logs	bashkit	1ce7cb3	Commit Preview URL Branch Preview URL	Oct 17 2026, 09:42 AM

[chaliy]

Generate Rust Coverage is failing, and it is not this PR's.

All 2438 integration tests passed. The job then crashed in tarpaulin's profraw merge:

INFO cargo_tarpaulin::statemachine::instrumented: Merging coverage reports

thread 'main' (2421) panicked at llvm_profparser-0.14.0/src/instrumentation_profile/mod.rs:58:35:
internal error: entered unreachable code: llvm_profparsers works on complete data

Why it isn't this PR's:

• This diff is one workflow YAML, one Python test and one knowledge markdown file — zero Rust. It cannot change which .profraw files tarpaulin writes or how they merge.
• The identical failure already happens on main: run 38974642137 (ca149cc, Oct 16) panicked at the same crate, same file, same line mod.rs:58:35, with the same message, in the same "Merging coverage reports" step, also after its tests passed.

Root cause is upstream: llvm_profparser 0.14.0 hits unreachable!() on a truncated/incomplete .profraw, which happens when one of the many instrumented test processes is reaped before flushing its profile. No fix exists to port — it needs a tarpaulin/llvm_profparser bump (or --skip-clean/serialized profraw collection) and that is its own change, not something to widen this PR with.

Re-running the failed job once to confirm. If it recurs here and on main, the durable fix is a separate PR against the coverage workflow.

---

Generated by Claude Code