ci: run checks and publish on release branches

[radu-mocanu]

Scopes both workflows to release/** in addition to main.

 # ci.yml
   push:
     branches:
       - main
+      - 'release/**'
     paths-ignore:
       - pyproject.toml
   pull_request:
     branches:
       - main
+      - 'release/**'

 # cd.yml
   push:
     branches:
       - main
+      - 'release/**'
     paths:
       - pyproject.toml

Why

Hotfix releases are cut on release/* branches, per the open-source hotfix procedure, but both workflows are scoped to main only.

Checks never run. ci.yml fires only for PRs targeting main, so a PR into a release branch gets no lint and no tests. Unlike main, release/* is not covered by a ruleset in this repo, so the missing checks do not block the merge — they are simply absent. That is the worse failure mode of the two: a hotfix can land with nothing verifying it. #130 merged that way; it was verified by a local run rather than by CI.

Publishing never happens. cd.yml fires only on push to main, so merging a hotfix into its release branch publishes nothing and every release needs a manual workflow_dispatch. A dispatch also runs the workflow file from the dispatched ref, so a branch cut from an older commit runs an older CI definition than main's.

Is auto-publishing from a release branch safe

The pypi environment has no deployment branch policy or protection rules, so a release ref is already permitted to publish, and the trigger stays filtered to paths: pyproject.toml, so only a version or dependency change starts a run.

Two things worth deciding alongside this:

• the publish step does not pass skip-existing, so a push touching pyproject.toml without a version bump fails at upload rather than no-op. Happy to add it.
• release/* has no ruleset here, so after this change a direct push to a release branch could publish without review. If you want the same guarantee main has, the ruleset should be extended to refs/heads/release/* as well. Say the word and I will add it to this PR.