ci(rebase-stack): skip native gh-stacks, re-enable for the rest

[behinddwalls]

Summary

Why?

PR #443 disabled this workflow outright (if: false) when the repo moved to GitHub's native stacked PRs. That was too blunt: native stacks and hand-rolled arh chains coexist here today. Stacks #470, #472 and #474 are native, while #460 → #461 → #462 → #463 → #476 is a plain chain whose every member reports stack: null. With the workflow off, merging any PR in a hand-rolled chain leaves the children still carrying their parent's commits — precisely the broken-diff problem this workflow was written to fix.

GitHub owns the lifecycle of its own stacks: on a partial merge it rebases and retargets the surviving members itself, so the workflow must not touch those. It only needs to tell the two apart rather than give up on both.

What?

Re-enables the job and skips only the PRs GitHub actually owns, instead of switching the whole workflow off.

A detect_stack helper resolves native-stack membership from GET /repos/{owner}/{repo}/pulls/{n}. It queries the REST API at run time rather than reading github.event.pull_request.stack off the webhook payload, so a PR added to a stack after the merge event was queued is still recognised. Membership survives merge — a merged member still reports its stack — which is what makes the lookup meaningful at this point in the lifecycle.

The check is applied per child PR, not to the merged PR. GitHub only ever rebases a stack's own members; a PR that targets a member's head branch without joining the stack is invisible to that machinery. Skipping the whole chain whenever the merged PR happened to be a stack member would therefore strand such a PR with exactly the broken diff this workflow exists to prevent. rebase_chain always runs; each child that is a stack member is skipped and not recursed into, while its siblings rebase normally. Membership of the merged PR is logged for context and gates nothing.

Presence is tested on the stack object itself rather than on stack.number. Probing a sub-field means a stack object arriving without that field reads as "standalone" and gets force-pushed — the unsafe direction to fail in. The number is used only for logging. An unreadable response still falls back to standalone, since the Stacks API 404s when the feature is not enabled for a repo, which is exactly when the rebase is wanted.

cleanup_orphaned_merged_branches still runs on every merge, including those where every child turned out to be GitHub's to rebase. This workflow therefore remains the sole owner of head-branch deletion, and native-stack head branches are reaped here too, each on the first merge after GitHub has retargeted its successors off it.

This depends on "Automatically delete head branches" being OFF, as the header has always documented — otherwise GitHub retargets children to main before the job runs and the non-native path silently no-ops on a green job. The setting has been turned off on the repo.

Test Plan

✅ YAML parses; job if and step env verified after the edit.

✅ bash -n clean on the extracted run: block under bash 5.2, the version Actions runners use. Note for future edits: macOS /bin/bash 3.2 reports a spurious syntax error near ';;' on this script — it cannot parse the heredoc nested in $( ), so it blames a line far from the real construct.

✅ actionlint v1.7.7 — clean.

✅ zizmor v1.25.2 (--no-online-audits, the version CI pins) — no findings, 2 ignored and 5 suppressed, confirming the existing .github/zizmor.yml exceptions still cover the file.

✅ yamlfmt v0.16.0 -lint — clean.

✅ detect_stack exercised against live PRs in this repo:

PR	.stack	Result
#467	stack #470, position 4/6, merged	native → skipped
#468	stack #470, position 5/6, open	native → skipped
#404	stack #472	native → skipped
#457	stack #475, size 1	native → skipped
#443	null	standalone → rebased
#460	null	standalone → rebased
#999999	HTTP 404	warns, treated as standalone, no set -euo pipefail abort

✅ The sub-field trap verified directly: a synthetic {"stack":{"id":51488,"position":4,"size":6}} with no number reads as standalone under .stack.number // empty, and as in-a-stack under the expression shipped here.

✅ Observed reference case — the merge of #467 (position 4 of stack #470). GitHub retargeted #468 from preetam/stovepipe-buildsignal-outcome to main and left #469 on #468's branch, confirming both that GitHub handles its own members and that a merged member retains its stack object.

The rebase itself can only be exercised post-merge. On the next merge of a hand-rolled chain (the runway series is the live case) watch for === Stack rebase complete === and a child retargeted with only its own commits; on a native-stack merge watch for each member child logging skipped: belongs to native stack #N, followed by the branch sweep. The first sweep will also reap preetam/stovepipe-buildsignal-outcome, which is currently orphaned — it merged after auto-delete was turned off and has no open dependents.