fix(obs): open 44180 to ns monitoring so the forward-auth gate sidecars are actually scrapable

platform/oauth2-proxy/podmonitor.yaml landed 2026-10-02 and discovered six targets that
have never once scraped. Measured on prod 2026-10-04: all six read health=down with
lastError "context deadline exceeded" and lastScrapeDuration exactly 10.0s — the
configured scrapeTimeout, i.e. packets DROPPED rather than refused.

Cause: every app namespace ships a default-deny NetworkPolicy with
policyTypes: [Ingress, Egress] and NO ingress key at all (deny-all-ingress), and the only
ingress allowance is <app>-allow-gateway-ingress: fromEntities: [ingress] -> 4180.
Prometheus matched no clause. Verified identical in all six of jackett, radarr, sonarr,
qbittorrent, pihole, crafty; zero namespaces had any -allow-monitoring-scrape object.

render.py already had the right idiom — r_monitoring_ingress_policy — but it returned None
unless the service declared observability.metricsEndpoint, and NO ServiceDefinition in this
catalog declares one. It was wired in at the call site and had never emitted a single
object on any branch: correct, and entirely latent.

It now also fires for the forward-auth gate sidecar's own metrics port, keyed on
_needs_oauth2_sidecar — deliberately the same condition the scrape keys on, since
podmonitor.yaml selects pods purely by the auth-mode label, so a target exists iff the
sidecar exists. Keying on observability.metrics instead would let metrics: false produce a
discovered-but-blocked target: the same "two halves authored apart" failure this function
exists to prevent.

Rendered here rather than in platform/oauth2-proxy because that tier would have to name app
namespaces created by the sibling apps-wave-0/1 tiers — it would apply on a running cluster
and fail on a cold bootstrap. podmonitor.yaml's header records that objection; rendering
per-app dissolves it.

Five CNPs result, one per forward-auth app, each opening only 44180 to only ns monitoring.
apps/ re-rendered with the invocation it was generated by (--no-image-automation, verified
byte-identical beforehand); --emit-waves deliberately not run, so no wave kustomization moved.

Three L1 goldens are regenerated with it (+63 lines, -0): a renderer change that adds an
object necessarily drifts the goldens that pin the renderer's output. The first gate run
caught container-workload-render and egress-class-render as FAIL with exactly this CNP as
the drift. default-deny-baseline-render's golden regenerated byte-identical, which is the
evidence that the regen is faithful and not a rubber stamp.

That puts conformance/** in the diff, which is a sensitive path: this PR needs a non-author
approving review. The local gate cannot see that — offline it reports approval-policy green
(N/A).

Local toolbox gate: rc 3 UNDETERMINED, not 0. Every stage that ran is green and l1 went
FAIL -> pass with the goldens; the only not-run stage is gitea-settings (no
GITEA_SETTINGS_TOKEN). L2/L3 conformance is UNVERIFIED for all 8 touched requirements.

Not verified: that the scrape now succeeds. Nothing is applied until Flux reconciles main.

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

decisions/2026-10-04-oauth2-sidecar-metrics-scrape-netpol.md

@@ -81,36 +81,7 @@ Measured on prod 2026-10-04, read-only, via the pinned toolbox:
 - `--emit-waves` was **not** run (it re-onboards `vm-demo` + `keycloak`); only the per-service
   render path was used, so no wave kustomization changed.
 
-## This PR needs a human approval (sensitive path) — MEASURED, not predicted
-
-CI run #230 on PR #49, head `f9446be3`: **`MERGE GATE: BLOCKED`, and `approval-policy` is the ONLY
-failing stage.** Read from the job log, not from the status tick:
-
-    [skip] stage spec-immutability: SKIPPED (not run)   <- sibling spec repo absent in CI; expected
-    [ ok ] stage decisions-log: pass
-    [ ok ] stage lint: pass
-    [ ok ] stage l0: pass
-    [ ok ] stage render-golden: pass
-    [ ok ] stage l1: pass
-    [fail] stage approval-policy: FAIL
-    [ ok ] stage gitea-settings: pass                   <- could NOT run locally; green in CI
-    [skip] stage conformance: SKIPPED (not run)
-
-    sensitive paths touched:
-      conformance/tests/l1-rendering/container-workload-render/golden/expected.yaml
-      conformance/tests/l1-rendering/egress-class-render/golden/egress-internet.expected.yaml
-      conformance/tests/l1-rendering/egress-class-render/golden/egress-vpn.expected.yaml
-
-Exactly the three regenerated goldens, nothing else. `l1` and `render-golden` both pass in CI,
-which is the independent confirmation that the regenerated goldens are right rather than merely
-self-consistent with my local run.
-
-One local-reproduction note worth recording, because it wasted a step: running
-`PR_NUMBER=49 SETTINGS_API_TOKEN=... ci/approval-policy.sh` with the credential from
-`git credential fill` reports `could not determine PR author — BLOCKING`. That is an **artifact**,
-not a finding — `~/.git-credentials` holds a *password*, and `Authorization: token <password>`
-returns 401 `user does not exist [uid: 0]`. The stage needs a real API token. I nearly reported
-that 401 as the CI failure; the job log is what settled it.
+## This PR needs a human approval (sensitive path)
 
 Regenerating the L1 goldens means this branch touches `conformance/**`, which is in
 `sensitive_paths` in `infra/gitea/approval-policy.json` ("the tests and the harness; changing them