ci: run CI for stacked PRs whose base is a feature branch

[ManSio]

What

One-line change to the CI trigger: pull_request now also fires for feature branches, not only for main.

Why

The workflow listened only to pull_request: branches: [main], so a stacked PR (base = feature branch) produced no CI run at all. That is exactly what happened to phases 2 and 3 of the migration:

• feat(search): on-demand cosine rerank path behind flag (Phase 2) #74 (Phase 2, on-demand rerank) and feat(search): MSCODEBASE_DENSE_OFF kill-switch + EXP-28 dense-off A/B #75 (Phase 3, dense-off) were stacked on each other and shipped with a local clean-state run as the only evidence.
• Their status was never verifiable on GitHub, and the PR body had to say so explicitly — an admission that the pipeline, not the code, was the problem.

Fixing the code afterwards would have been the wrong order: this removes the reason the evidence had to be a caveat.

Scope

• pull_request: [main, 'feat/**', 'exp/**', 'fix/**', 'chore/**']
• push: unchanged (main only), so a single revision is never built twice.

Job list unchanged: test, clean-state, manifest-parity, transport-equiv-e2e, docker-build. The workflow YAML parses and was verified locally before pushing.

Cost

Stacked PRs now consume CI minutes (ubuntu + windows + clean-state ≈ 5 min). That is the intended trade: an unverified merge is worse than a slower one.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 8018ff88-05b6-4a21-b7ce-15e9368ca47e

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}