MAINT: Run CI on release branches

[varunj-msft]

Description

The build_and_test, diff_cover, docker_build and frontend_tests workflows filtered pull requests on release/**, but release branches are named releases/vx.y.z, so the filter never matched anything, and their push triggers listed only main. Only docs.yml used the correct pattern, which is why it was the sole workflow to run on past release branches: releases/v1.0.1 and releases/v1.0.0 each have exactly two Actions runs, both build-book. The four workflows now match docs.yml — releases/v* on push, releases/** on pull request.

diff_cover keeps its pull request trigger limited to main, because diff coverage compares against origin/main and a release branch differs from it by the whole release. It gains the manual trigger the other three already had.

Running these workflows on release branches exposed two problems that were previously invisible:

• The alembic revision immutability check compares the branch against origin/main. A release branch cut from an earlier tag carries cherry-picked commits that legitimately edit already-released revisions, so the check reported intentional work as violations. It now skips history comparison on release branches while still checking staged changes.
• The concurrency groups keyed on github.head_ref, which is empty for a push, so every push formed its own group and nothing was ever superseded. They now fall back to github.ref. Note this also changes main: back-to-back pushes now cancel the earlier run, which is what the block's own comment always claimed it did.

Tests and Documentation

Adds tests/unit/build_scripts/test_enforce_alembic_revision_immutability.py with 19 tests covering push, pull request, merge queue and tag refs, the local git rev-parse fallback, branch names that only look like release branches, and that staged violations still fail on a release branch. pytest tests/unit/build_scripts/ passes 266 tests.

doc/contributing/11_memory_models.md stated the revision immutability rule without qualification, so it now records the release branch exception alongside it.

No notebooks are affected, so JupyText was not run.

[Behnam (behnam-o)]

Looks good, thank you! just a little comment on the precommit hook update

[Behnam (behnam-o)]

Could we avoid skipping both history checks on release branches? In CI the staged index is clean, so this effectively removes automated immutability enforcement. For release PRs, we could compare against origin/${GITHUB_BASE_REF} instead of origin/main; for pushes/merge queue, HEAD~1..HEAD should remain applicable. This avoids false positives from divergence while still detecting modified or deleted revisions.