docs(869): make the 258-250 arithmetic close, and scope the host offset to DST

Two precision findings from a cold review of the previous commit. Both claims
in that commit verified true; these are wording defects in my own text, and the
first is exactly the failure mode that commit set out to prevent.

The record said the difference between the repo-wide all-time figure and this
workflow's own was "three since-deleted probe workflows". 258 - 250 = 8, and 8
appeared nowhere in that file — so a reader checking the arithmetic finds a
mismatch and goes off to "correct" a number that is already right. The residual
is 8 runs from 3 workflows; both copies now say so, and they agree.

And "+02:00 / the host is UTC+2" is DST-scoped. The same API payload renders
`+01:00` for winter-dated fields, so a reader checking in January sees a doc
that contradicts what is on screen. Now named as the zone — Europe/Brussels,
+02:00 in August, +01:00 in winter — which is true year-round.

Also folded a duplicated sentence in the workflow comment: "every one of the 210
is this file" appeared twice with the 258 figure wedged between.

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

@@ -88,16 +88,17 @@ name: Review verdict
 #
 # What IS established on 1.27.1, and stated no wider than it was measured: `pull_request_target`
 # 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 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.)
+# runs started strictly after the 2026-08-05 upgrade (measured 2026-09-02). The WINDOW is part of
+# the claim, and an earlier draft got it wrong by citing the all-time REPO-WIDE figure: 258 runs /
+# 233 shas = 44 before the upgrade date + 4 ON it + 210 after. Citing 258 here would have imported
+# 1.25.4 evidence into a 1.27.1 sentence. This workflow's own all-time count is 250; the difference
+# is 8 runs from three since-deleted probe workflows, all pre-upgrade — which is why every one of
+# the 210 post-upgrade runs is this file.
 # The 4 same-day runs are excluded rather than assigned, because the upgrade landed mid-session and
 # 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.
+# time. Read those as UTC deliberately: this endpoint returns `started_at` Z-suffixed, while other
+# Gitea timestamps render in the host zone, Europe/Brussels — `+02:00` in August, `+01:00` in
+# winter — so a UI comparison shows different clock times.
 # 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
 # only the injected `secrets.GITEA_TOKEN`. Both of those stay 1.25.4-dated.

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

@@ -39,13 +39,14 @@ establishes only WHICH COMMIT each trigger reads its definition from. It says no
 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 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 **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
+workflow's own all-time count is 250 — the difference is **8 runs** from 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 **UTC** start times cannot be
+placed either side of it without the exact upgrade time, so they go to the side that weakens the
+claim. Read those times as UTC deliberately: this endpoint returns `started_at` Z-suffixed, while
+other Gitea timestamps render in the host zone, Europe/Brussels — `+02:00` in August, `+01:00` in
+winter — so a UI comparison shows different clock times. **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
 injected `secrets.GITEA_TOKEN`. Both stay 1.25.4-dated.