ci: run on pull requests against any base branch

[petlenz]

The pull_request trigger filtered on branches: [main], so a PR targeting a feature branch matched nothing.

Work in this repo lands through stacks — #27, #28, #29, #30 and #31 all target a feature branch — and not one of them has ever been built or tested by CI. The most recent workflow run of any kind is main from 2026-07-28.

   push:
     branches: [main]
   pull_request:
-    branches: [main]

Dropping the filter runs the job for every pull request whatever its base. The push trigger keeps its main filter, so branch pushes add no load — a stacked branch is covered by its own PR rather than by pushes to it.

The job body needed no change: NUMSIM_BUILD_TESTS and NUMSIM_BUILD_EXAMPLES are the real option names in CMakeLists.txt, and g++-14 is installed and selected, which the <print> uses in the examples and plot targets require.

Branched from main rather than folded into one of the stacked PRs, since the trigger is repo policy and not part of any feature. It has been merged into each of #27–#31 as well, because pull_request runs the workflow from the PR's merge ref — the fix has to be present on a head branch for that PR to get a run.

[petlenz]

Third review pass. No findings — three lines, and it does exactly what it says.

Worth recording what it has bought since merging into the stack: seven real defects surfaced, none of which any local build here could reach, because find_package succeeds on this machine for both Eigen and nlohmann and the fetch path therefore never ran.

[petlenz]

This PR is redundant — recommend closing unmerged.

Verified by containment: ci/run-on-all-pull-requests is a strict ancestor of every other open branch, including feature/drucker-prager (#10), which also targets main.

ci/run-on-all-pull-requests  <  feature/drucker-prager      (#10 -> main)
ci/run-on-all-pull-requests  <  feature/vector-solver       (#17)
ci/run-on-all-pull-requests  <  ...and all 8 others

So merging #10 delivers this change to main regardless. Merging both is harmless but adds a PR to track for no content.

The one argument for keeping it: it is 3 lines against #10's 4176, so merging it first turns CI on for main immediately rather than waiting on a large review. If #10 is not close to merging, that is worth something. If it is, close this.

Its value is already banked either way — turning the trigger on surfaced seven latent defects across #10, #17 and #30, none of which any local build here could reach.

[petlenz]

Closing as redundant: feature/drucker-prager (#10) already removes the branches: [main] filter, and every PR in the stack inherits it. Once #10 lands on main, this diff is empty.