Revert the enforcement experiment, and record what it measured

Both experiments are in, and together they answer the question the scope of
#5 rests on - with an answer that is not the one the plan assumed.

MEASURED, run 888 on this branch:

  Install-test cyberchef   SUCCESS, 1m9s   probe port 8080 restricted to
                                           192.0.2.11/32, which cannot be the
                                           k3d node's address
  Install-test outline     FAILURE, 5m59s  DNS egress rule removed, so
                                           "postgres" and "redis" do not
                                           resolve and /_health cannot pass

So: POLICIES ARE ENFORCED in the install-test - outline's pod never became
Ready and rollout status timed out after six minutes, which is the net this
rollout needs. But THE KUBELET'S PROBE TRAFFIC IS EXEMPT from policy in k3s:
cyberchef became Ready in 69 seconds with its probe port restricted to an
address no probe can come from.

What that changes, and what it does not:

  - The plan's claim was "a policy that blocks the probe path makes the
    install-test red". That is NOT true here, and it is now measured rather
    than assumed. The install-test's net is for EGRESS and for anything the
    application itself needs, not for the probe path.
  - It does not undermine the rollout, because this convention never restricts
    a probe port by default - the rule is rendered without a "from" until an
    operator sets probeSources. The trap CI cannot see is therefore not
    triggered by this PR; it is triggered by a deliberate narrowing, which is
    what the NOTES.txt sentence and ci/run-networkpolicy-test.sh's fourth
    assertion exist for.
  - It raises the stakes for the render assertions. A wrong ingress port - the
    NodePort mistake above all - would leave the pod Ready in CI (probes exempt)
    and no ingress controller runs there either, so nothing in the pipeline
    would notice. That failure is caught mechanically by assertion 2 or not at
    all.
  - And it says nothing about the production cluster, whose CNI is Calico, not
    k3s'. There, probe traffic is subject to policy, which is exactly why the
    default stays open.

Part of #5

outline/templates/outline.networkpolicy.yaml

@@ -140,27 +140,15 @@ spec:
       {{- end }}
   egress:
     {{- /*
-    TEMPORARY - THIS COMMIT IS AN EXPERIMENT AND IS REVERTED IN THE NEXT ONE.
-
-    The DNS rule is REMOVED here on purpose. Everything about the scope of
-    Gitea #5 rests on the install-test enforcing NetworkPolicies, and the first
-    experiment did not settle it: restricting cyberchef's probe port to an
-    address that cannot be the node's left the install-test GREEN. That has two
-    possible causes and they are very different - either k3s' policy controller
-    exempts the kubelet's probe traffic, which would be good news for this
-    convention, or it enforces nothing at all, which would mean there is no net
-    under this rollout.
-
-    This separates them, unambiguously and without touching a probe. Outline
-    resolves "postgres" and "redis" by name, and all three of its probes hit
-    /_health, which checks BOTH stores. With no DNS rule and policyTypes
-    Egress, every lookup fails.
-
-    EXPECTED: the pod never becomes Ready, rollout status times out, the
-    outline install-test goes RED - which proves egress is enforced.
-    If it goes GREEN, nothing is enforced in CI and the scope of this issue has
-    to be renegotiated rather than pushed through.
+    DNS, unconditionally. There is no value to switch this off, and that is
+    deliberate: a knob whose only other setting breaks every name lookup in
+    the pod is a trap and not a feature.
     */}}
+    - ports:
+        - protocol: UDP
+          port: 53
+        - protocol: TCP
+          port: 53
     {{- /*
     Postgres. The port, not the host - outline.secrets.dbSecretRef carries a
     connection URL the chart never parses, so this is the STANDARD port and not