docs(decisions-log): the approval-policy check this PR was expected to fail does not exist

I was briefed to expect CI to FAIL on an `approval-policy` check, because `conformance/**` is
security-relevant. Measured instead:

  grep -rn approval .gitea/workflows/            -> no match
  branches/main status_check_contexts            -> ['gate / gate (pull_request)']
  commits/<head>/statuses  gate / gate           -> success, "Successful in 1m36s"
                           gate / conformance    -> pending, "Blocked by required conditions"

The only required context is `gate / gate`, and it is green — and it genuinely ran (1m36s), so
this is not the skipped-Gitea-job-reports-success trap. There is no path-based approval policy
in CI anywhere in this repo. What blocks the merge is `required_approvals: 1` and the fact that
`gitea-admin` authors every agent PR and cannot self-approve — the control that returned HTTP
405 on PR #12.

Recording it because the PR body and the log entry both asserted the wrong blocker, and this
repo has been burned repeatedly by documentation that described a control nobody measured. A
change to the admission boundary under `conformance/**` is gated by a generic human approval,
not by anything that knows the path is security-relevant; if that is the intent, it is not
implemented.

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

DECISIONS-LOG.md

@@ -5233,8 +5233,34 @@ Nothing FAILED. rc 3 is the expected local outcome and `gate.yml` tolerates it.
 - `ci/conformance.sh` still runs the suite **locally** and is untouched (plan §3 item 4).
   This branch changes nothing about what CI does today.
 
-### PR
+### PR #20 — and a correction to what was expected to block it
 
-Opened against `main`, **not merged**. Its CI is **expected to FAIL on `approval-policy`**:
-`conformance/**` is security-relevant and needs a human approval. That is the control
-working; it was not worked around.
+Opened against `main`, **not merged**. I was briefed to expect CI to FAIL on an
+`approval-policy` check because `conformance/**` is security-relevant. **That check does not
+exist.** Measured rather than assumed:
+
+    grep -rn approval .gitea/workflows/     ->  no match
+    GET /repos/.../branches/main
+      protected                    True
+      user_can_push                False
+      enable_status_check          True
+      status_check_contexts        ['gate / gate (pull_request)']
+      required_approvals           1
+    GET /repos/.../commits/<head>/statuses
+      success   gate / gate (pull_request)          Successful in 1m36s
+      pending   gate / conformance (pull_request)   Blocked by required conditions
+
+So: the **only** required context is `gate / gate`, and it is GREEN (1m36s — it ran; this is
+not the skipped-job-reports-success trap). There is **no path-based approval policy in CI at
+all**. What actually stops this merging is `required_approvals: 1` plus the fact that
+`gitea-admin` authors every agent PR and cannot self-approve — the same control that returned
+HTTP 405 on PR #12. `gate / conformance` is "Blocked by required conditions", i.e. the
+`CLUSTER_AVAILABLE` guard, unchanged.
+
+**Consequence worth acting on:** a change under `conformance/**` — including a change to the
+admission boundary itself — is gated by a *generic* human approval, not by anything that knows
+the path is security-relevant. If the intent is "security-relevant paths get a stricter
+review", that policy is not implemented anywhere in this repo. `CODEOWNERS`-style path review
+or a `paths:`-scoped required check would be the mechanism; neither exists today.
+
+The PR was **not merged** and nothing was worked around.