style(no-slop): remove every em-dash + banned words across all modules + capstone

Apply the no-ai-slop standard (now binding in AGENTS.md): the em-dash character is
banned outright (restructured, not blind-replaced), plus the banned word/phrase
list (delve, leverage, robust, seamless, truly, unlock, etc.). 0 em-dashes remain
in modules + capstone; the only "robust" left is the planted M10 ai-change.patch
trap. Module H1 titles use a colon separator.

All deliberate teaching devices preserved; labs compile/parse (py/sh/yaml/json);
no junk. AGENTS.md updated with the hard no-slop rules.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT

modules/23-working-with-existing-codebases/lab/skills/map-this-repo.md

@@ -2,7 +2,7 @@
 
 A navigation playbook (a Module 21 skill) for orienting in a codebase you didn't write.
 Point Claude Code (or sub your own agent) at this file as a skill, or paste it in as instructions. The goal is a
-**read-only** mental model — no edits happen here.
+**read-only** mental model; no edits happen here.
 
 ## When to use
 At the start of any session on an unfamiliar repo, before any change is discussed.
@@ -19,7 +19,7 @@ At the start of any session on an unfamiliar repo, before any change is discusse
    `ARCHITECTURE`, or committed AI-instructions file. Treat these as claims to verify, not truth.
 2. Identify the **entry points**: how does this thing start? (CLI `main`, web server, library
    exports.) Name the exact file(s).
-3. Trace **one representative request/command end to end** — from entry point to where it does its
+3. Trace **one representative request/command end to end**, from entry point to where it does its
    real work and back. List the files it passes through, in order.
 4. Produce an **architecture summary** (max ~1 page):
    - One paragraph: what this project does and how it's structured.

modules/23-working-with-existing-codebases/lab/skills/safe-change.md

@@ -2,7 +2,7 @@
 
 A safe-change playbook (a Module 21 skill) for modifying a codebase you don't fully understand.
 Use it only **after** `map-this-repo` has produced an architecture summary. The whole bet of this
-skill is: small, scoped, tested, reviewable — never a sweeping rewrite.
+skill is: small, scoped, tested, reviewable, never a sweeping rewrite.
 
 ## When to use
 When making a concrete change to an unfamiliar repo.
@@ -10,10 +10,10 @@ When making a concrete change to an unfamiliar repo.
 ## Rules
 - **One change, one branch.** Create a branch first (Module 6). Never work on the default branch.
 - **Smallest diff that solves it.** Touch the fewest files possible. If the change wants to sprawl,
-  stop and re-scope — sprawl in code you don't understand is how you break things invisibly.
+  stop and re-scope; sprawl in code you don't understand is how you break things invisibly.
 - **No drive-by edits.** Do not reformat, rename, or "clean up" unrelated code. Those bury the real
   change and make the diff unreviewable (Module 10).
-- **Match local conventions.** Mirror the surrounding code's style, naming, and patterns — not your
+- **Match local conventions.** Mirror the surrounding code's style, naming, and patterns, not your
   own defaults.
 - **Tests are the contract.** A change isn't done until it's covered (Module 13) and the existing
   suite still passes.
@@ -22,12 +22,12 @@ When making a concrete change to an unfamiliar repo.
 1. **State the change in one sentence** and the acceptance criterion ("done when X").
 2. **Find the blast radius first:** search for every caller/usage of what you're about to touch.
    List them. If you can't enumerate them, you're not ready to change it.
-3. **Install the project's dependencies, then run the existing tests before touching anything** —
+3. **Install the project's dependencies, then run the existing tests before touching anything**;
    establish a green baseline. Tell two failures apart: if the suite errors with missing imports,
-   "no module named …", or "no tests ran," that's an **unconfigured environment**, not a baseline —
-   finish the documented install (and pick a different repo if it still won't go green on a clean
+   "no module named …", or "no tests ran," that's an **unconfigured environment**, not a baseline.
+   Finish the documented install (and pick a different repo if it still won't go green on a clean
    clone). A genuine **pre-existing failure** (install succeeded, but a real test fails) is the other
-   case — note it so it doesn't get blamed on you, and don't build on top of it.
+   case: note it so it doesn't get blamed on you, and don't build on top of it.
 4. **Make the minimal edit.** Keep it to the files identified in step 2.
 5. **Add or extend a test** that fails without your change and passes with it.
 6. **Run the full suite.** All green, including the baseline tests.