ci: run push workflows only on develop, main and release tags

Every commit on a branch with an open PR ran the whole pipeline twice, once
for the push and once for the pull_request event, in separate concurrency
groups. Filter the push trigger to develop, main and v* tags so other
branches run CI and publish their images only through their PR. Tags are
listed explicitly because a branch filter alone stops tag pushes.

Update the trigger, benchmark and image prose in the README and the Gitea
Actions guide to match.

Refs #309

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/gitea-actions.md

@@ -11,10 +11,13 @@ message.
 
 ## Jobs and triggers
 
-Every branch and tag push runs CI. Pull requests run on opening, reopening,
-synchronization, and title/body edits. Manual dispatch runs validation without
-publishing images. There is no schedule or deployment job in the preserved
-configuration; the Compose files remain manual deployment options.
+Pushes to `develop` and `main` and `v*` tag pushes run CI. Other branches
+(feature, renovate, release, hotfix) run it only through their pull request; a
+branch without a PR gets no automatic CI or image, so open a draft PR to get
+one. Pull requests run on opening, reopening, synchronization, and title/body
+edits. Manual dispatch runs validation without publishing images. There is no
+schedule or deployment job in the preserved configuration; the Compose files
+remain manual deployment options.
 
 | Job         | Behavior                                                                                                                                                                                                                                                                                                                                                        |
 | ----------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
@@ -27,18 +30,19 @@ configuration; the Compose files remain manual deployment options.
 | `images`    | Publishes branch/SHA images after required validation, including the benchmark, or promotes an existing SHA image for a stable tag, running the publisher with Bun. Runs only for pushes and same-repository PRs.                                                                                                                                               |
 | `required`  | Fails on failed, cancelled, or skipped required validation, including the benchmark. Requires image publication when expected; accepts its intentional skip for fork PRs and manual dispatch. It is shell only and needs no Bun.                                                                                                                                |
 
-The benchmark runs on both push and pull_request events: the push run gates image
-publication (`images.needs` includes `benchmark`) and the `required` aggregate.
-The relative gate absorbs a slower runner and load that lasts through the whole
-job, because calibration runs in the same job. It calibrates before and after the
-protocol and judges against the slower value, so it also absorbs load that starts
-during the protocol, such as an overlapping push and pull_request run of the same
-commit. It does not absorb load that ends before the second calibration; the
-240-second hang guard still bounds those runs.
+The benchmark gates image publication (`images.needs` includes `benchmark`) and
+the `required` aggregate. The relative gate absorbs a slower runner and load
+that lasts through the whole job, because calibration runs in the same job. It
+calibrates before and after the protocol and judges against the slower value,
+so it also absorbs load that starts during the protocol, such as another run
+sharing the runner. It does not absorb load that ends before the second
+calibration; the 240-second hang guard still bounds those runs.
 
-Push and PR runs are separate so PR title and rebase checks run on the PR event.
-New runs cancel older runs for the same event/ref. Image jobs serialize per
-branch slug; stable promotions share one group and are not cancelled in progress.
+Because branch pushes outside `develop` and `main` do not trigger CI, a commit
+on a PR branch runs only on PR events, which carry the PR title and rebase
+checks. New runs cancel older runs for the same event/ref. Image jobs serialize
+per branch slug; stable promotions share one group and are not cancelled in
+progress.
 
 ## Runners and permissions
 
@@ -112,10 +116,10 @@ only one place fails CI instead of drifting.
 ## Images and releases
 
 Images use the [Gitea container registry](https://docs.gitea.com/usage/packages/container/)
-at `gitea.nessar.fr/nessar/vac-optimizer`. Branch pushes and same-repository PRs
-publish `branch-<slug>` and `sha-<full commit SHA>`. Slugs retain the previous
-lowercase, non-alphanumeric-to-hyphen, 63-byte normalization; choose distinct
-branch slugs.
+at `gitea.nessar.fr/nessar/vac-optimizer`. Pushes to `develop` and `main` and
+same-repository PRs publish `branch-<slug>` and `sha-<full commit SHA>`. Slugs
+retain the previous lowercase, non-alphanumeric-to-hyphen, 63-byte
+normalization; choose distinct branch slugs.
 
 Only stable `vX.Y.Z` tags matching the tagged commit's `package.json` version
 and reachable from `main` may promote images. Promotion first pulls the existing
@@ -148,7 +152,7 @@ secrets. Complete the remaining activation checks in this order:
    `git show 0d900fd72d1a405d257f5a566c55cc0cb3d2bc61:.gitlab-ci.yml`.
 2. Publish the reviewed feature branch and open its PR to register the workflow.
    Once registered, manual dispatch verifies validation and artifacts without
-   publishing images. Push and PR validation can also run now; their image and
+   publishing images. PR validation can also run now; its image and
    aggregate checks remain blocked until publisher secrets are provisioned.
 3. Verify runner isolation and Docker service support, then provision the two
    publisher secrets. Review the package publisher's permissions and registry