Mid-stack PRs miss stack-aware `pull_request` triggers: PRs are created before the stack object exists

从 gh stack submit 流程开始，使用针对 main 进行过滤的 pull_request 工作流重现四分支 stack。跟踪成员 PR 何时创建、stack 何时注册，以及如何通过 check suites 观察工作流触发行为。完成标准是每个成员 PR 都收到预期的工作流运行，包括在 stack 注册之前创建的 stack 中间 PR。

What happened

On gh stack submit, PRs are created a few seconds before the stack object itself exists. pull_request workflows with a branches: filter are evaluated against each PR's literal base at open time, so mid-stack PRs are filtered out and never dispatched. They are not re-evaluated once the stack is registered, so they permanently show no checks.

This contradicts the documented behaviour in Optimizing CI for stacked pull requests: "A workflow configured to run on pull_request events targeting main runs for every pull request in the stack."

Reproduction

1. In a repo with the stacks preview enabled, add a workflow with:

   on:
     pull_request:
       branches: [ "main" ]
   

2. Create a 4-branch stack and gh stack submit.

3. Observe CI runs only on the bottom PR and the topmost PR. The middle PRs get a check suite with zero runs.

Observed timeline

Stack of 4 (PRs #10–#13, stack #14, stack.base.ref = main, size: 4):

The bottom PR runs because its base is literally main, independent of any stack awareness. The top PR runs because its dispatch landed after stack registration at 13:24:26 and got a second check suite. PRs #11 and #12 had their opened events fully processed before the stack existed, were rejected by the branches: [main] filter, and nothing re-dispatched them afterwards.

Reproduced identically on an earlier stack of 3 in the same repo: bottom PR ran, middle skipped, top ran.

Expected behavior

Every PR in the stack is evaluated against stack.base.ref, as documented — either by creating the stack before its PRs, or by re-evaluating pull_request workflow triggers for all member PRs once the stack is registered.

Actual behavior

Only PRs whose trigger evaluation happens after stack registration get stack-aware treatment. Mid-stack PRs are silently left with no checks, which is indistinguishable from "queued" and blocks merge on repos with required checks.

Not a duplicate of

• #319 — merge refs are healthy here: refs/pull/{10,11,12,13}/merge all exist and point at current commits, and all four PRs report mergeable: true.
• #379 — that concerns paths filters being selected from the topmost PR. This is branches filters and a registration-ordering race; the affected PRs get a check suite with zero runs rather than a workflow selected from the wrong PR.

Workaround

Remove the branches: filter from the pull_request trigger so CI runs regardless of base.