ci: run ci and codeql checks on pull requests to any base branch

[aheritier]

🤖 Automated implementer agent — this comment was posted by the implementer bot from Docker Agentic Platform, not by a human developer

What

Removes the branches: [ main ] filter from the pull_request trigger in
ci.yml and codeql.yml. Two deleted lines, nothing else — push triggers
are untouched in both files, and no job, step, if: guard, permission or
concurrency setting is modified.

Why

branches: on a pull_request trigger matches the PR's base branch, not
its head. A stacked PR's base is a parent feature branch, not main, so ci
and codeql never fire on it. All three checks the repo ruleset requires to
merge into main — lint, build-and-test, license-check — live in
ci.yml, so a stacked PR today gets no build, test, lint, licence or security
signal at all.

Evidence: PR #4074 (base fix/startable-toolset-backoff) has no ci or
codeql run in any state, while its sibling #4062 (base main, same author,
same day) has the full set. The only workflows that ran on #4074 are the ones
with no branches: filter (docs-lint, docs-a11y, docs-upstream). There
are 14 stacked PRs open right now (#4016–#4030), so this is a live, ongoing
gap, not a hypothetical.

Flagging for review

1. CI cost. Every stacked PR now runs the full matrix: lint,
   build-and-test, windows-tests, license-check, build-image on two
   runners, and three CodeQL analyses. On a 14-deep stack, each restack
   re-runs the whole chain — a real increase in CI minutes. If this proves too
   costly, the right lever is gating the expensive build-image job, not
   re-introducing a base-branch filter (that would bring back the exact gap
   this PR closes).
2. Scope. This makes the required checks run and report on stacked
   PRs; it does not make them blocking there. All three rulesets are
   scoped to ~DEFAULT_BRANCH, so a red stacked PR can still be merged into
   its parent branch — reviewers will just be able to see that it's red now.
   Extending enforcement to feature branches is a separate repo-settings
   decision, deliberately left out of this PR.

Publishing is unaffected

build-and-push-image, merge-and-push-image and merge-and-push-template
are each guarded by
if: github.event_name != 'pull_request' && !github.event.repository.fork,
and the push trigger stays scoped to main and v* tags. Broadening the
pull_request trigger cannot cause a stacked PR to push an image or manifest.

Testing

• actionlint v1.7.12 (the same linter CI runs via raven-actions/actionlint)
  exits 0 with no findings on both patched files.
• task build/task test are not applicable — no Go code is touched.