docs(skills): rewrite container-security descriptions to a uniform standard

All 33 container-security skills now carry what it does, an explicit
"Use when" trigger, keywords, and a negative trigger naming the nearest
neighbour. Six collision clusters resolved by differentiating scope
rather than merging, so no skill is removed:

- kube-bench: running the tool vs interpreting findings into an audit
- Calico: portable upstream NetworkPolicy vs Calico-as-CNI vs Calico-only
  CRDs (GlobalNetworkPolicy, HostEndpoint, DNS egress)
- Falco: deploying and operating it vs authoring escape rules
- container escape: tool-agnostic runtime signals vs Falco rule syntax vs
  static posture audit vs offensive breakout
- Trivy: all-target platform and operator vs single-image scan
- Docker: images and Dockerfiles vs daemon.json vs the CIS audit script

Also replaces the templated "When to Use" boilerplate in these files,
including bullets that only restated the skill's own name.

Worst pair (Pod Security Standards vs Pod Security Admission) drops from
0.77 cosine to below the 0.45 threshold. Repo-wide: colliding pairs
60 -> 56, skills involved 105 -> 94.

skills/implementing-pod-security-admission-controller/SKILL.md

@@ -1,10 +1,17 @@
 ---
 name: implementing-pod-security-admission-controller
-description: Implement Kubernetes Pod Security Admission (PSA), the built-in admission
-  controller stable since v1.25, to enforce Privileged, Baseline, and Restricted
-  Pod Security Standards at the namespace level with enforce, audit, and warn modes,
-  replacing the deprecated PodSecurityPolicy. Use when hardening Kubernetes namespaces,
-  migrating off PodSecurityPolicy, or enforcing pod-level security baselines.
+description: >-
+  Configures and operates the Kubernetes Pod Security Admission (PSA) controller
+  that enforces Pod Security Standards: namespace enforce/audit/warn labels,
+  cluster-wide defaults via AdmissionConfiguration, exemptions for usernames,
+  runtime classes and namespaces, version pinning, and troubleshooting pods the
+  controller rejected. Use when wiring PSA up on a cluster, setting cluster-wide
+  default enforcement, exempting system namespaces, debugging why a pod was
+  rejected or why enforcement is not firing, or reading PSA audit and warning
+  output. Keywords: Pod Security Admission, PSA, admission controller,
+  AdmissionConfiguration, pod-security.kubernetes.io labels, enforce audit warn,
+  exemptions, kube-apiserver. Do not use for choosing which security profile a
+  workload needs - use implementing-kubernetes-pod-security-standards.
 domain: cybersecurity
 subdomain: container-security
 tags:
@@ -37,10 +44,16 @@ Pod Security Admission (PSA) is a built-in Kubernetes admission controller (stab
 
 ## When to Use
 
-- When deploying or configuring implementing pod security admission controller capabilities in your environment
-- When establishing security controls aligned to compliance requirements
-- When building or improving security architecture for this domain
-- When conducting security assessments that require this implementation
+- Wiring PSA up on a cluster for the first time
+- Setting cluster-wide default enforcement via `AdmissionConfiguration`
+- Exempting system namespaces, service accounts, or runtime classes from enforcement
+- Debugging why a pod was rejected, or why enforcement is silently not firing
+- Staging a safe rollout: `warn` and `audit` first, `enforce` once violations reach zero
+- Pulling PSA violations out of the kube-apiserver audit log
+
+**Not this skill:** deciding which profile a workload should run under, or what
+`securityContext` changes Restricted demands. Use
+`implementing-kubernetes-pod-security-standards`.
 
 ## Prerequisites