ci: skip PR runs when targeting a non-main base branch

[jrusso1020]

What

Adds branches: [main] to the pull_request: trigger of each workflow that runs on PRs:

• ci.yml
• regression.yml
• windows-render.yml
• docs.yml
• catalog-previews.yml

One line added per file. PRs whose base is something other than main (typical for stacked PRs targeting another feature branch) no longer trigger these workflows.

Why

CI usage was saturated earlier today — partly from ~14 simultaneously-active Vance branches, partly from the general pattern of Graphite-stacked PRs triggering the full matrix (styles-a..g, fast, render-compat, hdr, Windows render, CodeQL) once per level of the stack. On a 5-PR stack that's 5× the CI work, most of which is redundant: once the bottom of the stack merges, the next PR rebases to main and re-runs anyway.

After this change:

Scenario	Before	After
PR targeting main	Full CI	Full CI (unchanged)
Stacked PR (base = another feature branch)	Full CI	No CI
Stacked PR rebased to main	Full CI	Full CI (re-fires on base change)
push to main	Full CI	Full CI (unchanged)

Paired with #425 (concurrency groups), this should take a meaningful bite out of the hosted-runner contention we saw this afternoon.

Tradeoffs

• Con: Mid-stack PRs lose CI signal until they reach the top of the stack. For short stacks this is fine — the convention with stacked PRs is to land them quickly and rely on the final-in-stack CI. For long-lived stacks it could hide regressions longer.
• Mitigation: contributors who want mid-stack signal can re-target a PR to main temporarily, or push changes to an ancestor to force the stack to merge-down.
• The concurrency: groups from ci(regression): add concurrency group to cancel superseded runs #425 already cancel superseded runs within a single branch — so the combination is "cancel wasted runs on the same branch" + "don't open runs on stacked bases in the first place."

Not touched

• publish.yml — already filters to branches: [main] on the pull_request: types: [closed] trigger.
• CodeQL — default-setup configured in the org UI, not a repo YAML. If CodeQL on stacked PRs becomes noisy, it can be adjusted in repo settings.

Test plan

• Unit tests added/updated — N/A (workflow config)
• Manual testing performed — diff is minimal (+ branches: [main] in one place per file), YAML is valid (lefthook format check passed), and branches: filtering on pull_request: is a standard GitHub Actions feature with documented semantics: https://docs.github.com/en/actions/writing-workflows/choosing-when-workflows-run/triggering-a-workflow#running-your-pull_request-workflow-based-on-the-head-or-base-branch-of-a-pull-request
• Documentation updated (if applicable) — N/A

Once merged: the next stacked PR anyone opens (base ≠ main) should skip CI. A subsequent rebase to main will re-fire CI as expected.