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-kubernetes-pod-security-standards/SKILL.md

@@ -1,12 +1,17 @@
 ---
 name: implementing-kubernetes-pod-security-standards
 description: >-
-  Configures Kubernetes Pod Security Standards (Privileged, Baseline, Restricted)
-  enforced via the built-in Pod Security Admission (PSA) controller (Kubernetes
-  1.25+), including namespace labeling and enforce/audit/warn modes. Use when
-  hardening pod configurations against privilege escalation, migrating off
-  deprecated PodSecurityPolicy, or setting namespace-level pod security
-  enforcement.
+  Chooses and applies the correct Kubernetes Pod Security Standard (Privileged,
+  Baseline, Restricted) for a workload: what each profile forbids, how to map
+  existing workloads to a profile, which securityContext fields must change, and
+  how to plan a PodSecurityPolicy-to-PSS migration without breaking running pods.
+  Use when deciding which pod security profile a namespace or workload should run
+  under, auditing which workloads would fail Restricted, planning a PSP migration,
+  or mapping pod security posture to a compliance control. Keywords: Pod Security
+  Standards, PSS, Privileged, Baseline, Restricted, securityContext, runAsNonRoot,
+  drop ALL capabilities, seccomp RuntimeDefault, PSP migration. Do not use for
+  configuring the admission controller that enforces these profiles - use
+  implementing-pod-security-admission-controller.
 domain: cybersecurity
 subdomain: container-security
 tags:
@@ -38,10 +43,15 @@ Pod Security Standards (PSS) define three levels of security policies -- Privile
 
 ## When to Use
 
-- When deploying or configuring implementing kubernetes pod security standards 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
+- Deciding whether a namespace or workload belongs at Privileged, Baseline, or Restricted
+- Auditing which existing workloads would be rejected if Restricted were enforced today
+- Translating a "must meet Restricted" requirement into concrete `securityContext` changes
+- Planning a PodSecurityPolicy migration and predicting what will break before it does
+- Mapping pod security posture to a compliance control (NIST PR.PS-01, CIS Kubernetes)
+
+**Not this skill:** configuring the controller that enforces these profiles — namespace
+labels, `AdmissionConfiguration`, exemptions, or debugging a pod PSA rejected. Use
+`implementing-pod-security-admission-controller`.
 
 ## Prerequisites