CI-9 follow-up: the summary said "mechanically", the blind spots say otherwise

The residual-risk paragraph at the top of checks.yml claims the `guard the
trigger` step "keeps it that way mechanically rather than by asking the next
editor to read this comment". For blind spots 1 and 3 that is not true: the
guard lives inside the workflow a filter makes Gitea skip, so for those cases
the defence IS the comment.

That paragraph is the preamble someone reads at the exact moment they are
editing the trigger, so a summary running ahead of its detail is worse here
than elsewhere. It now points at the blind spots and states spot 3 plainly:
a filter naming a branch nothing targets is itself skipped, lands green and
untested, and then skips every subsequent pull request - the gate off for
everything, silently.

Flagged by the reviewer on PR #95 (issuecomment-1424) as non-blocking.

This PR is also the first real test of CI-9's fix on release/1.0 itself. Run
806 was a workflow_dispatch and posts no commit status at all, so it verified
content but never the gate. This one has to post `checks / unit
(pull_request)` as success rather than skipped.

Verified before push: the guard passes against this edited file (whose new
prose quotes `branches: [main]` and `master`) and still refuses a genuine
filter added to the `on:` block.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BwRLw7eKYj2byVdwB6kbjU

.gitea/workflows/checks.yml

@@ -110,6 +110,18 @@ name: checks
 # trigger` step below then keeps it that way mechanically rather than by asking
 # the next editor to read this comment.
 #
+# ⚠️ READ THE BLIND SPOTS ON THAT STEP BEFORE TRUSTING THE SENTENCE ABOVE.
+# "Mechanically" holds only for a reintroduced filter that still names the
+# PR's own base. For blind spots 1 and 3 the defence IS this comment, because
+# the guard lives inside the workflow that a filter makes Gitea skip. Blind
+# spot 3 is the one that matters: a filter naming a branch nothing targets
+# (`branches: [main]` from a template - this repo has no `main`, and no pull
+# request in 99 has ever targeted `master`) is itself skipped, lands green and
+# untested, and then every subsequent pull request is skipped too. That is the
+# gate off for everything, silently. Closing it needs a SECOND permanently
+# unfiltered workflow posting its own context, with that context added to
+# `release/1.0`'s `status_check_contexts` - a forge change, with the owner.
+#
 # THE MEASUREMENT, because the obvious guess is wrong and was nearly written
 # here as fact. A skip-ci keyword in a commit message (`[skip ci]`, `[ci skip]`,
 # `[no ci]`, `[skip actions]`, `[actions skip]`) does NOT behave like a filter