ci: gate feature branches via pull_request only (dedupe PR-push runs)

A push to a branch with an open PR fired both the `push` and `pull_request`
triggers, running the gate (and manifests) twice. On Gitea those runs are
byte-identical: unlike GitHub it has no merge-preview ref, so its
`pull_request` checks out `refs/pull/N/head` — the same commit a branch push
would. Scope `push` to `main` and let `pull_request` gate feature branches:
halves CI on every PR push, loses no coverage, and is forward-compatible — if
Gitea ever adds the merge ref, these runs upgrade to testing the merged result
for free.

.gitea/workflows/ci.yaml

@@ -14,11 +14,16 @@
 name: ci
 on:
   push:
-    # Branch pushes only — a tag push hits the same commit the branch push
-    # already gated, so `branches: ['**']` drops the redundant tag-triggered
-    # run (the release workflow owns tags). Pushing commits + a tag together
-    # still gates the commits via the branch push.
-    branches: ['**']
+    # Only `main` (the post-merge gate + canonical branch). Feature branches
+    # are gated via `pull_request` instead. Running both on a push to a PR'd
+    # branch was pure duplication on Gitea: unlike GitHub it has no merge-
+    # preview ref — its `pull_request` checks out `refs/pull/N/head`, the same
+    # commit a branch push would, so the two runs were byte-identical
+    # (docs.gitea.com/usage/actions/faq). Gating on `pull_request` is also
+    # forward-compatible: if Gitea ever adds the merge ref, these runs upgrade
+    # to testing the merged result for free. Tags stay unmatched (release.yaml
+    # owns them).
+    branches: [main]
     # Skip the gate for changes that can't affect clippy/test — docs, markdown,
     # and the website subproject (it has its own workflow, website.yaml, that
     # builds + publishes it). A push touching crate code *and* these still runs