feat(curriculum): Phase 6C module upgrades, security assessment bank, ROOT 11 orientation

Upgrades six PARTIAL modules to the gold-module standard (lesson/demonstration/
knowledge-check/guided-exercise/lab(s)/reflection), preserving every existing lab
activity_id and scenario_id: root-06-m03 (jobs/cronjobs/daemonsets), root-07-m04
(ingress/networkpolicy), root-07-m02 (configuration/secrets, converted in place
from a bare 5-lab bank), root-09-m02 (serviceaccounts/rbac), root-09-m03
(network/supply-chain security), root-10-m03 (troubleshooting framework).

root-05-m01 (20-task kubectl-fluency bank) gets a minimal bookending lesson +
reflection rather than a full redesign, since each task already carries its own
explanation. root-12-m01, root-capstone-m01, and root-09-m04 are promoted to
READY via documented exceptions (no new activities) where adding one would
misrepresent their intentional design.

Wires a new rootnode-security-assessment (exam, 60min, hint_policy disabled)
using the existing Phase 3B assessment engine: 3 required hands-on CORE
scenarios + 4 random-draw pools covering SecurityContext, RBAC, network
policy, and the 7 previously-unwired CKS MCQs. Wires the previously-unwired
readiness-probe-task scenario as an OPTIONAL practice lab in root-10-m01,
using the existing is_required model.

Adds root-11-m01-devops-platform-thinking — an honest, lesson-only ROOT 11
orientation module naming DevOps/platform engineering practices already
exercised in ROOT 05-10/12, explicit that GitOps/CI-CD/IaC/observability need
lab infrastructure this platform doesn't yet provide. No fake labs.

Adds infra/scripts/validate-course-content.js: cross-checks the DB against
scenario/content files for duplicate ids, orphans, invalid references, cycles,
sequence collisions, instructor-notes leakage, and (new) self-paced content
deferring explanation to a live instructor. 0 errors against the resulting
22 courses/modules, 163 activities, 98 scenario files.

No application code changed — every gap was satisfiable with existing tables
(course_modules, module_activities, assessment_definitions) and the existing
content-delivery pipeline.

Co-Authored-By: Claude Sonnet 5 <[email protected]>

content/root/root-09-kubernetes-security/m03-network-and-supplychain-security/09-reflection.md

@@ -0,0 +1,41 @@
+# Reflection: Reachability and Trust Are Decisions You Make on Purpose
+
+You just applied default-deny NetworkPolicy, egress restriction, TLS ingress, and image-pull
+authentication for real. Take a few minutes to connect these to a single underlying principle.
+
+## Reflection questions
+
+1. Four different mechanisms in this module (NetworkPolicy ingress, NetworkPolicy egress, TLS,
+   image-pull secrets) all express the same underlying idea in a different layer. What is that
+   idea, stated in one sentence?
+2. If you had to prioritize implementing ONLY ONE of this module's controls on a brand-new,
+   unsecured cluster, which would you pick first, and why?
+3. How would you explain, to someone who thinks "our cluster is internal, so it doesn't need
+   this," why internal-only still benefits from all four controls?
+
+## Real Ops takeaway
+
+**Trust should be explicit, narrow, and verifiable — never assumed from proximity.** A Pod on
+the same cluster, a request from inside the corporate network, an image from "a registry we
+usually use" — none of these are actually trustworthy by default. Every control in this module
+replaces an assumption ("it's internal, it's probably fine") with an explicit, checkable
+decision (this specific Pod can reach this specific destination; this specific registry is
+authenticated; this specific connection is encrypted).
+
+**Supply-chain and network security compound.** A compromised image with unrestricted egress on
+an open network is a far worse incident than the same compromised image on a hardened one — the
+controls in this module don't individually prevent every incident, but together they
+dramatically shrink what any single failure can turn into.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 1 is the module's thesis — make sure
+students can actually articulate it in their own words, not just recognize it when stated.
+
+**Approximate timing:** 8-10 minutes live discussion; 5 minutes self-paced writing.
+
+**Optional extension:** ask students to rank this module's four controls by how much
+IMPLEMENTATION EFFORT each typically requires on a real team, separately from security value —
+a good exercise in real-world prioritization tradeoffs.