docs(869): mark the run timestamps UTC and the all-time figure repo-wide

Two clarifications from the round-5 gate, both raised as non-blocking and both
the kind of thing that sends a later reader off to "correct" a number that is
already right.

The `started_at` values are UTC, while other Gitea timestamps in this repo
render +02:00 and the host is UTC+2 — so "17:41-22:36" does not match what the
run shows in the web UI. Under local-time bucketing the split would read
44/2/212 rather than 44/4/210; the stated numbers stay conservative either way
(210 <= 212), but only if the reader knows which clock they are on.

And 258/233 is the REPO-WIDE all-time count. This workflow's own all-time count
is 250 — the other 8 are three since-deleted probe workflows, all pre-upgrade,
which is also why every one of the 210 post-upgrade runs is this file. Someone
recomputing the workflow-scoped figure gets 250 and would otherwise think 258
was wrong.

Refs #869

Decisions-Edit: yes
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Whe75djeAEuZpdNk6KU7No

.gitea/workflows/review-verdict.yml

@@ -90,9 +90,13 @@ name: Review verdict
 # fires for THIS workflow continuously — 210 such runs across 189 distinct head shas, counting only
 # runs started strictly after the 2026-08-05 upgrade (measured 2026-09-02). Every one of the 210 is
 # this file. The WINDOW is part of the claim, and an earlier draft got it wrong by citing the
-# all-time figure: 258 runs / 233 shas = 44 started before the upgrade date + 4 ON it + 210 after.
+# all-time REPO-WIDE figure: 258 runs / 233 shas = 44 before the upgrade date + 4 ON it + 210 after.
+# (This workflow's own all-time count is 250; the other 8 are since-deleted probe workflows, all
+# pre-upgrade, which is why all 210 post-upgrade runs are this file.)
 # The 4 same-day runs are excluded rather than assigned, because the upgrade landed mid-session and
-# their 17:41-22:36 start times cannot be placed either side of it without the exact upgrade time.
+# their 17:41-22:36 UTC start times cannot be placed either side of it without the exact upgrade
+# time. Read those as UTC deliberately: this endpoint returns `started_at` in UTC while other Gitea
+# timestamps render `+02:00`, and the host is UTC+2, so a UI comparison shows different clock times.
 # Citing 258 here would have imported 1.25.4 evidence into a 1.27.1 sentence.
 # What that does NOT establish, deliberately: WHICH `types:` fire (a run count identifies no event
 # type), and whether the STORED secret store is reachable under this trigger — this job references

docs/decisions/records/ci/gate-trigger-base-resolved.md

@@ -38,10 +38,13 @@ establishes only WHICH COMMIT each trigger reads its definition from. It says no
 **What IS established on 1.27.1, stated no wider than it was measured:** `pull_request_target` fires
 for `review-verdict.yml` continuously — **210 such runs across 189 distinct head shas**, counting only
 runs started strictly after the 2026-08-05 upgrade (measured 2026-09-02). All 210 belong to this
-workflow. The WINDOW is part of the claim: the all-time figure is 258 runs / 233 shas, which splits
+workflow. The WINDOW is part of the claim: the all-time REPO-WIDE figure is 258 runs / 233 shas (this
+workflow's own all-time count is 250 — the difference is three since-deleted probe workflows, all
+pre-upgrade), which splits
 44 before the upgrade date + 4 ON it + 210 after, so citing 258 here would import 1.25.4 evidence
 into a 1.27.1 sentence. The 4 same-day runs are excluded rather than assigned — the upgrade landed
-mid-session and their 17:41-22:36 start times cannot be placed either side of it without the exact
+mid-session and their 17:41-22:36 **UTC** start times (this endpoint returns `started_at` in UTC while
+other Gitea timestamps render `+02:00` — the host is UTC+2) cannot be placed either side of it without the exact
 upgrade time, so they go to the side that weakens the claim. **What that
 deliberately does NOT establish:** WHICH `types:` fire, since a run count identifies no event type;
 and whether the STORED secret store is reachable under this trigger, since the job references only the