docs(plan): L2/L3 conformance CI wiring plan; gate.yml placeholder -> plan pointer

HAND-OFF 2 (L2/L3 conformance wiring) — DEFERRED with a concrete plan, per the
hand-off's escape hatch (too risky to wire live cluster access from CI autonomously;
do NOT hand CI a broad kubeconfig).

The intended seam (in-cluster Chainsaw Job under its own scoped SA; CI holds only a
narrow trigger credential) is mostly scaffolded but not safe to finish autonomously:
- ci/conformance.sh still runs run.sh locally rather than triggering the in-cluster Job.
- conformance/incluster/chainsaw-job.yaml has no repo-clone init-container and the stock
  chainsaw image lacks bash/python3/kubectl/git that run.sh needs.
- No trigger SA/RBAC/credential exists, and the core blocker is a privilege-escalation
  design question: any `create jobs` credential in the conformance namespace can create a
  Job running as the privileged conformance-runner SA. This needs an admission constraint
  (recommended: narrow trigger SA + a Kyverno policy pinning the admissible Job shape), or
  a GitOps-native zero-credential trigger — an operator decision.
- conformance/incluster/ isn't wired into Flux; Gitea vars/secrets aren't provisioned.

docs/plans/l2-l3-conformance-ci-wiring.md captures current state, the security analysis,
the functional gaps, a file-by-file step sequence, validation/rollback, and the open
decisions. gate.yml's conformance placeholder now points to it (still if:false, honest).

Co-Authored-By: Claude Opus 4.8 <[email protected]>

.gitea/workflows/gate.yml

@@ -84,15 +84,16 @@ jobs:
       # Gitea-compatible @v3 action or Gitea's own artifact backend if retention is wanted.
 
   # ───────────────────────────────────────────────────────────────────────────
-  # PLACEHOLDER — NOT WIRED (STOP-and-report item, WS-GITOSS Phase 6).
-  # L2/L3 conformance (Chainsaw behavioural + fault-injection) needs a LIVE cluster.
-  # Turning this on is a design decision with two open sub-decisions:
-  #   1. Toolchain: build+push a pinned CI image to the Gitea container registry and
-  #      reference it as the job image, vs. install-in-job from ci/versions.env (slower).
-  #   2. Cluster creds: how the runner reaches the cluster — the intended model is an
-  #      in-cluster Chainsaw Job driven by its OWN scoped ServiceAccount (CI holds only a
-  #      narrow trigger credential; the runner mounts NO SA token today). That SA + RBAC
-  #      + the trigger secret do not exist yet.
+  # PLACEHOLDER — NOT WIRED (deferred; concrete plan written, awaiting operator decision).
+  # L2/L3 conformance (Chainsaw behavioural + fault-injection) needs a LIVE cluster and is
+  # gated behind vars.CLUSTER_AVAILABLE + a narrow secrets.CONFORMANCE_TRIGGER_KUBECONFIG.
+  # The intended model: an in-cluster Chainsaw Job (conformance/incluster/) under its OWN
+  # scoped ServiceAccount — CI holds NO broad kubeconfig, only a trigger credential. The
+  # blocker is a real privilege-escalation design question (a `create jobs` credential can
+  # create a Job running as the privileged runner SA), plus a runner image + repo-clone +
+  # results-collection that don't exist yet. Full analysis + step sequence:
+  #   docs/plans/l2-l3-conformance-ci-wiring.md
+  # The blueprint job shape is retained dormant in merge-gate.yaml.
   # Kept `if: false` so it never runs (shows skipped, never fakes green — HARD RULE 4).
   # ───────────────────────────────────────────────────────────────────────────
   conformance: