fix(testing/ci/tooling): consistent unittest, venv guidance, runnable lab commands

- #9: standardize the test chain on stdlib unittest (nothing-to-install, which
  keeps M13's claims true and its planted bug intact). Aligned M5/M14/M16 prose,
  M14 lab/test_tasks.py, and ci/gitlab starters; ruff stays the only pip install.
- #20: add venv / PEP 668 / which-python guidance to M20 (+ M14/M15 local
  installs); point MCP config at the venv's absolute python.
- #21: replace M21 Part D's empty `git diff HEAD~1` with `git log -p` (no
  .gitignore added — device preserved).
- #22: add a dependency-install step before M23's green baseline on a fresh clone.
- #23: M24 reviewer/triage now tolerate code-fence-wrapped JSON (stdlib only);
  feature.patch trap untouched.
- #28: fix M27 Part D CI snippet path (working-directory) and require the gate to
  target a varying candidate; swapped_model regression kept as the fixture.

Closes #9
Closes #20
Closes #21
Closes #22
Closes #23
Closes #28

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

modules/21-skills-teaching-the-ai-your-playbook/README.md

@@ -234,10 +234,13 @@ seen, producing all four parts without you listing the steps.
 
    ```bash
    git log --oneline add-command.md   # the procedure's own history
-   git diff HEAD~1 add-command.md      # if you tightened it in Part C — your workflow change as a diff
+   git log -p -- add-command.md        # full patch history: the file's creation, plus the Part C tighten if you made one
    ```
 
-   That diff *is* a change to how your team adds commands — readable, attributable, revertable. In a
+   (`git log -p` surfaces the skill's own patches no matter what you committed *after* tightening it —
+   unlike `git diff HEAD~1`, which would be empty here because the most recent commit added the second
+   *command*, not a change to the skill.) Each entry in that history *is* a change to how your team adds
+   commands — readable, attributable, revertable. In a
    team repo (Modules 8, 11) it reaches everyone on `git pull`; behind review (Module 10) it lands as a
    PR someone approves. You've turned a procedure you used to narrate into a versioned capability.