docs(pm-agent): record the PR's own CI result, read from the log not the status tick

The PR gate ran and BLOCKED on approval-policy alone — the sensitive-path rule, with no
non-author review — while every technical stage passed, gitea-settings included (the one
stage a workstation cannot run). That is the gate working, and it is the one thing an
agent must not clear for itself.

Also recorded: the commit-status API reported 'pending — Waiting to run' for a run that
had already completed, so the log is the source of truth here. §2b again.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

decisions/2026-10-05-pm-agent-issue-to-pr.md

@@ -80,6 +80,27 @@ All offline, in the pinned toolbox (`./infra/devcontainer/dev.sh run`), never on
   The gate names that single stage as the reason for rc 3 ("Stages that did not run:
   gitea-settings"), so nothing in the change is unexamined — but rc 3 is not a pass and this
   entry does not call it one.
+- **The PR's OWN CI run, read from its log rather than from the status tick** (PR #57, head
+  `8b5e950b`, `.gitea/workflows/gate.yml` with `GATE_STRICT_SKIPS=true` and
+  `REQUIRE_GITEA_SETTINGS=true`): decisions-log **pass**, lint **pass**, l0 **pass**,
+  render-golden **pass**, l1 **pass**, **gitea-settings pass** — including
+  `block_admin_merge_override = true`, which is the one stage my workstation cannot run at
+  all — spec-immutability **SKIPPED** (the spec repo is absent in CI, as its own step
+  tolerates), conformance **SKIPPED**, and **approval-policy FAIL → MERGE GATE: BLOCKED**.
+  The failure is *only* the sensitive-path rule: "This PR changes the pipeline or the
+  security posture it rests on, and has NO approving review from anyone other than its author
+  ('gitea-admin')", over eleven paths — `clusters/{base,dev,prod}/*`,
+  `platform-config/kustomization.yaml`, `platform/kyverno/{admission,tests}/pm-agent*`,
+  `platform/pm-agent/rbac.yaml` and `platform/pm-agent/pm-agent-credentials.sops.yaml`.
+  **That is the gate working, not a defect in the change**, and it is the one thing an agent
+  must not clear for itself: the operator posts `/approve-override <reason>` as a PR *review*,
+  or a non-author reviews it. CI is therefore red and will stay red until a human acts.
+- **The commit-status API did not reflect any of that.** While the run completed and its log
+  carried the verdict above, `GET /commits/{sha}/status` still reported
+  `gate / gate (pull_request): pending — Waiting to run`. Worth knowing before anyone builds
+  automation on that endpoint: on this Gitea the status tick lagged the run indefinitely, so
+  the log is the source of truth. A fresh instance of §2b — "a green tick is not proof
+  anything ran"; here the tick was not even wrong, it was absent.
 - **The gate caught two real defects in this change before I did**, which is worth recording
   because both were in the parts I was most confident about:
   1. `flux-postbuild-substitution` → 1 UNDEFINED + 1 FATAL-PARSE. My ConfigMap's *comment*