gitea: subscribe the review hook to pull_request_review

The hook registered with no events at all and delivered nothing.
"pull_request_review_comment" and "pull_request_review_rejected" are real
HookEventTypes and real X-GitHub-Event-Type values, but they are not
things gitea's hook API accepts. updateHookEvents
(routers/api/v1/utils/hook.go) matches a fixed list of api names and
silently ignores anything else, so every event flag stayed false, the POST
succeeded, and the hook sat there inert.

There is no narrower api name: HasEvent (models/webhook/webhook.go)
collapses approved, rejected and review-comment onto
HookEventPullRequestReview, so `pull_request_review` is a single switch for
all three. Approvals consequently cannot be excluded at the hook any more.
They now cross the wire as "pull_request_approved", which is not in the
route's event list, so Hermes ignores them on the event match -- before the
filter script and before any LLM call. Gitea's delivery log will show them
answered 200/ignored, which is intended.

That makes three namespaces for the same event rather than two, so the
tables in both nix files and the README now carry the api column, and the
README warns about the silent-ignore behaviour that hid this.

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

hosts/mars/hermes-agent.nix

@@ -367,24 +367,34 @@ in
   # the file (mtime-gated) on the next delivery — no container restart, and no
   # `podman exec` quoting chain between nix and the prompt text.
   #
-  # Events are WIRE names (X-GitHub-Event), not subscription names. Gitea uses
-  # the same strings in two namespaces and they collide — from
-  # HookEventType.Event() in modules/webhook/type.go:
+  # Events are WIRE names (X-GitHub-Event). Gitea spells the same events three
+  # different ways and two of the spellings collide — from
+  # HookEventType.Event() in modules/webhook/type.go, and updateHookEvents in
+  # routers/api/v1/utils/hook.go for the api column:
   #
-  #   subscription name             wire name                what it is
-  #   ---------------------------   ----------------------   ------------------
-  #   issue_comment                 issue_comment            comment on an issue
-  #   pull_request_comment          issue_comment            comment on a PR
-  #   pull_request_review_comment   pull_request_comment     review with a body
-  #   pull_request_review_rejected  pull_request_rejected    changes requested
-  #   pull_request_review_approved  pull_request_approved    approval
+  #   HookEventType                 wire name (here)         api name (gitea.nix)
+  #   ---------------------------   ----------------------   --------------------
+  #   issue_comment                 issue_comment            issue_comment
+  #   pull_request_comment          issue_comment            pull_request_comment
+  #   pull_request_review_comment   pull_request_comment     pull_request_review
+  #   pull_request_review_rejected  pull_request_rejected    pull_request_review
+  #   pull_request_review_approved  pull_request_approved    pull_request_review
   #
-  # The hooks' `events` arrays in services/dev/gitea.nix take the SUBSCRIPTION
-  # name; Hermes matches these against X-GitHub-Event, i.e. the WIRE name. So
+  # Hermes matches these against X-GitHub-Event, i.e. the WIRE name. So
   # "pull_request_comment" HERE means a review and "issue_comment" HERE means
   # a comment — the exact inversion of how they read. X-GitHub-Event-Type
-  # carries the subscription name, but Hermes does not look at it. Both files
-  # therefore name the same event differently on purpose; neither is a typo.
+  # carries the HookEventType, but Hermes does not look at it. This file and
+  # services/dev/gitea.nix therefore name the same event differently on
+  # purpose; neither is a typo.
+  #
+  # The api column is not a third alias but a coarser set: HasEvent
+  # (models/webhook/webhook.go) collapses all three review types onto
+  # pull_request_review, so the gitea hook cannot subscribe them separately.
+  # Approvals arrive here as a result and are dropped by NOT being in
+  # prReviewEvents — Hermes answers {"status": "ignored"} on the event match,
+  # before the filter script and before any LLM call. Widening to approvals is
+  # a mars-side change only: add "pull_request_approved" to prReviewEvents and
+  # "pull_request_review_approved" to the filter's ALLOWED_REVIEW_TYPES.
   #
   # issue_comment on the wire covers comments on plain issues too; the hook
   # does not subscribe those, and the comment filter's is_pull check drops