feat(monitoring): negative-control Probe for paperless ingress scoping (REN-28 PR 2a)

Adds one Probe, `blackbox-negative-control-paperless`, with its own jobName
`blackbox-negative-control` and four tcp_connect targets in the `paperless`
namespace. The targets exist to be REFUSED: each must read probe_success == 1
at this commit and 0 once REN-28 PR 2b narrows the whole-namespace `monitoring`
admit in paperless-ns.yaml. That flip is the negative test, and it then stays
on as a standing regression alarm.

This is monitoring-only. No traffic-path change, no restart, no new grant, no
policy edit. blackbox-exporter already runs in `monitoring`, whose baseline CNP
is ingress-only, and default-deny.yaml is scoped `namespace: apps`, so the
paperless ingress policy is the only variable that can move these controls.

Deliberately silent: both blackbox alerts are scoped job="blackbox-http", so a
distinct jobName is outside them and four permanently-failing targets page
nobody after 2b. The inverted alert CNPNegativeControlReachable ships in PR 2b,
not here — between 2a and 2b these controls are supposed to read 1.

Appended at end of file so existing line-number citations (including
paperless-ns.yaml's reference to probes-blackbox.yaml:250) do not shift.

Refs REN-28 §5.6, §6.4. Revert: drop this one Probe document.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

kubernetes/apps/monitoring-rules/probes-blackbox.yaml

@@ -310,3 +310,76 @@ spec:
       static:
         - proxy-1.renner.uno:33080
         - proxy-2.renner.uno:33080
+---
+# NEGATIVE CONTROLS for the paperless ingress scoping (REN-28 PR 2a).
+#
+# These four targets are here TO BE REFUSED. They are not availability
+# monitoring: every one of them is a workload in the `paperless` namespace that
+# blackbox-exporter has no business reaching, and each must read
+# `probe_success == 1` today and `0` once REN-28's PR 2b lands. That flip is the
+# test. Without them, "the whole-namespace admit is gone" is an assertion about
+# a CNP diff rather than a measured property of the cluster, and a later
+# re-widening of the grant would be silent.
+#
+# Why this can only be the ingress policy under test: blackbox-exporter runs in
+# `monitoring`, whose baseline CNP (infrastructure/network-policies/
+# monitoring-ns.yaml) is ingress-only — it declares no `egress:` at all — and
+# the cluster's default-deny.yaml is scoped `namespace: apps`, which covers
+# neither `monitoring` nor `paperless`. So the only thing that can turn these
+# red is paperless's own ingress policy, which is exactly the variable. Nothing
+# else can make the test pass or fail.
+#
+# WHY A SEPARATE jobName, and why these must NEVER be folded into the
+# blackbox-http Probe above: after PR 2b these targets fail permanently and BY
+# DESIGN. BlackboxProbeFailing and BlackboxProbesAbsent
+# (prometheusrule-blackbox.yaml:35,50) are both scoped to job="blackbox-http",
+# so a distinct job is outside both and stays silent — and the hand-maintained
+# instance!~ exclusion regex at :35, whose fragility that file warns about, does
+# not have to grow a fifth entry. Adding these to blackbox-http instead would
+# page the on-call forever.
+#
+# The inverted alert that gives these targets teeth — CNPNegativeControlReachable,
+# `probe_success{job="blackbox-negative-control"} == 1` — ships in PR 2b, NOT
+# here. Between 2a and 2b these controls are SUPPOSED to read 1, so the alert
+# would fire on the correct state. Do not add it before the policy change.
+#
+# A bare TCP connect is the right probe: it completes or it times out, with no
+# application-layer ambiguity about whether a 403 meant the policy or the app.
+# Known, accepted side effect: the pprl-pg-rw connect opens and closes without a
+# startup packet, so Postgres logs "incomplete startup packet" at LOG level once
+# a minute until PR 2b lands and the connect stops arriving.
+apiVersion: monitoring.coreos.com/v1
+kind: Probe
+metadata:
+  name: blackbox-negative-control-paperless
+  namespace: monitoring
+  labels:
+    # Load-bearing, as noted at the top of this file: probeSelector matches on
+    # it. Without it this Probe is never discovered and the control reads
+    # `absent`, not `1` — which would look like a passing negative test.
+    release: kube-prometheus-stack
+spec:
+  jobName: blackbox-negative-control
+  prober:
+    url: blackbox-exporter-prometheus-blackbox-exporter.monitoring.svc.cluster.local:9115
+  module: tcp_connect
+  interval: 60s
+  scrapeTimeout: 10s
+  targets:
+    staticConfig:
+      static:
+        # Proves BOTH halves of the pprl-pg scoping PR 2b will introduce: the
+        # source (blackbox is not Prometheus, and the pprl-pg-allow-prometheus
+        # rule 2b adds admits only Prometheus) and the port (5432 is not the
+        # exporter's 9187). Neither that rule nor paperless-allow-blackbox
+        # exists yet at this commit — that is the point, and why this target
+        # must read 1 now. Service is CNPG-generated from Cluster `pprl-pg`
+        # (paperless/cluster.yaml:4) and is the name paperless itself dials
+        # (paperless.yaml:46).
+        - pprl-pg-rw.paperless.svc.cluster.local:5432
+        # Three witnesses that the whole-namespace `monitoring` admit is gone
+        # for workloads no new rule selects. Ports from the Services themselves:
+        # redis.yaml:76, tika.yaml:57, gotenberg.yaml:63.
+        - redis.paperless.svc.cluster.local:6379
+        - tika.paperless.svc.cluster.local:9998
+        - gotenberg.paperless.svc.cluster.local:3000