ci(workflows): run checks on stacked pull requests

[Harry19081]

Problem

CI and the PR contract check only trigger for pull requests whose base is
develop, release, or master:

on:
  pull_request:
    branches: [develop, release, master]

A stacked pull request targets another feature branch, so it matches no
trigger and runs no checks at all. Open stacks are affected today: on
#1220 and
#1222 the only check that ran was
Check AI attribution, which already uses an unfiltered pull_request
trigger. Neither PR has a typecheck, lint, unit-test, clippy, or
Enforce PR contract result, so the reported verification for both is
author-run only and nothing enforces the PR contract on them.

The same gap applies to every other stack in the repository, including the
codex/issue-* agent-org chain, where a defect can only surface once the
whole stack has landed on develop.

Solution

Drop the base-branch filter from both workflows so they run on every pull
request, matching the trigger check-ai-attribution.yml already uses.

Cost stays proportional to the diff, because the existing controls key off the
pull request rather than its base:

• the Detect CI scope job diffs base.sha...head.sha, which for a stacked PR
  is exactly that PR's own change, and skips the macOS clippy runner when no
  Rust file changed
• lint covers only changed files
• concurrency: ci-pr-<number> with cancel-in-progress still supersedes
  older runs for the same PR

Potential risks

• Runner usage rises. Stacked PRs that previously ran nothing now run CI.
  This is the intended effect, and scope detection means a frontend-only
  stacked PR does not allocate a macOS runner. Rust-touching stacked PRs do
  add a clippy run, which is the expensive job in this workflow.
• Enforce PR contract now applies to stacked PRs. Existing stacked PRs
  whose title or description does not meet .github/PR_RULES.md will start
  failing that check until their description is corrected. This is the point
  of the change, but it will surface as new red checks on PRs that were
  previously unchecked.
• pr-policy.yml keeps pull_request_target, so it still runs the workflow
  definition from the base branch. A stacked PR therefore only picks this up
  once its base branch contains this commit; the same is true for ci.yml via
  the merge commit. Landing this on develop fixes new stacks immediately and
  reaches the existing stacks when they next integrate develop.
• No job definition, permission, or toolchain version changed. Reverting is a
  one-line restore of each branches: filter.

Verification

• python3 -c "import yaml; yaml.safe_load(...)" on both workflows — parsed,
  with on resolving to {'pull_request': None} and
  {'pull_request_target': {'types': [...]}}
• pnpm exec prettier --check .github/workflows/ci.yml .github/workflows/pr-policy.yml — passed
• Confirmed against the live PRs that the gap is real: gh pr checks 1220 and
  gh pr checks 1222 each report only check (the attribution guard), while
  gh pr checks 1150, based on develop, reports the full set
• This pull request targets develop, so its own run exercises the changed
  ci.yml trigger
• Not run: no application code changed, so no typecheck, unit, or clippy run
  was performed locally for this diff

🤖 Generated with Claude Code