trigger CI on stacked PRs

[selmanozleyen]

Every CI workflow gates its pull_request trigger on branches: [main], so a PR that targets
any other branch never fires one. Stacked PRs target a feature branch by definition, so they
get no checks at all — and an empty check list reads as "nothing to report" rather than
"never ran", which is the dangerous part.

Seen live on #149: it had checks while its base was main, and the moment it was retargeted
onto feat/flatten_backends_module for the #148 → #149 → #150 stack, gh pr checks 149
started answering no checks reported on the 'feat/simplify_methods' branch.

Change

Drop the branches filter from pull_request in build.yaml, lint.yml, notebooks.yaml,
test-slow.yaml and test.yaml. push: branches: [main] is left alone, so branch pushes still
do not double-run alongside the PR event, and release.yaml is untouched (it triggers on
published releases).

on:
  push:
    branches: [main]
  pull_request:      # was: pull_request: { branches: [main] }

Each workflow already carries concurrency: group: ${{ github.workflow }}-${{ github.ref }}
with cancel-in-progress: true, so every PR in a stack gets its own independently-cancelled
run group.

One consequence worth expecting: when a parent PR merges, GitHub re-targets the child and its
checks re-run against the new base. That is the behaviour you want from a stack — it is what
catches a child that only passed against the old parent.

Verification

All five files parse, on.pull_request resolves to null (all branches, default activity types),
and pre-commit run --all-files is clean. The real check is this PR itself: it is based on
main, so it proves the workflows still fire on the default path. Retargeting any open PR onto
a feature branch after this merges is what proves the other half.