chore(ci): dogfood the chore(release) skip filter

[theogravity]

Summary

monorel's own ci/github/README.md documents a recipe telling downstream consumers to put

if: github.event_name == 'pull_request' || !startsWith(github.event.head_commit.message, 'chore(release):')

on every job that runs go mod tidy or otherwise resolves Go module versions. monorel's own CI didn't follow that recipe.

This PR applies the filter to the three jobs in ci.yml that resolve module versions (test, lint, tidy) and to the e2e job in e2e-gitea.yml. The two PR-only jobs in ci.yml (commit-lint, docs-build) already gate on github.event_name == 'pull_request'; no change needed.

Why now

The race the filter prevents doesn't currently bite monorel because it's a single-module repo and the chore(release) commit doesn't bump go.sum entries. Adding the filter is purely:

• Free CI minutes saved on chore(release) merges (the diff is CHANGELOG + .changeset/*.md deletion + monorel internal version string; nothing that warrants the full test matrix or the e2e Forgejo container).
• Demonstrates the recipe in monorel's own setup as a working reference for downstream consumers.
• Forward-compatible if monorel ever grows sub-modules (e.g., a hypothetical extracted library module someday).

Test plan

• After merge, the next non-chore(release): push to main triggers a clean CI run (every filtered job runs as before).
• At the next release-pr merge, the chore(release): commit's CI run shows test, lint, tidy, and e2e jobs as Skipped rather than Pass/Fail. release.yml still runs and tags the release; nothing else changes.

🤖 Generated with Claude Code