fix(modules-1,15,17): onboarding step, make M15 gate actually catch the plant, M17 .env override

- M1: add a no-git "Get the course materials" step (download+unzip; clone noted
  as Module 8) so Part A's paths resolve without assuming git. URL flagged
  Verify-before-publish (swap to public host before publishing).
- M15: security gate was failing OPEN on python3-only systems (bare `python`)
  and missing the UNTRACKED config.py, so the planted secret passed green. Now
  guards python3, fails CLOSED on any non-clean exit, and stages files so the
  planted SYNC_API_KEY + typosquat dep are actually caught.
- M15: correct the false "Bandit flags the API key" claim (B105-107 need
  password-named ids); add an honest MD5 (B324) flaw so the SAST demo fires.
  Planted secret/deps preserved.
- M17: require the .env loader to use setdefault so Part D's override demo works;
  explain precedence. Hardcoded "before" anti-pattern left intact.

Closes #6
Closes #17
Closes #18
Closes #19
Closes #29

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

modules/15-security-scanning/README.md

@@ -287,9 +287,14 @@ that key had been real and ever pushed, removing it now is not enough; you'd hav
 because it's in history. (Proper secret management is Module 17; this is just the catch.)
 
 > **Stretch — Gate 3 (SAST):** install a static analyzer for your language (for Python,
-> `pip install bandit`, then `bandit -r .`) and see it flag insecure patterns — including, often, the
-> very hardcoded secret from Part C, from a different angle. Note how much noisier it is than the
-> first two gates. That noise is why it's the one you tune.
+> `pip install bandit`, then `bandit -r .`) and watch it flag insecure *code you wrote* — here, the
+> MD5-based request signing in `config.py` (weak crypto, CWE-327). Now note what it does **not**
+> flag: the hardcoded `SYNC_API_KEY`. Bandit's hardcoded-credential checks (B105–107) key on
+> *password-named* identifiers — `password`, `secret`, `token` — so a key named `SYNC_API_KEY` slips
+> right past them. Catching that string is a secret scanner's job (Gate 2), not SAST's. Same file,
+> two distinct flaws, caught by two different gates with two different blind spots — which is exactly
+> why you run all three rather than trusting one. And note how much noisier SAST is than the first
+> two gates: that noise is why it's the one you tune.
 
 ### Part D — Wire the gates into CI
 
@@ -298,13 +303,32 @@ runs on every push and blocks the merge.
 
 1. Copy `lab/security-scan.sh` into your project. It runs the SCA and secret-scan gates and **exits
    non-zero on any finding** — which is what makes CI go red. Make it executable
-   (`chmod +x security-scan.sh`) and run it locally first:
+   (`chmod +x security-scan.sh`).
+
+   Before you run it, **stage the starter files** so the secret gate can see them:
+
+   ```bash
+   git add config.py requirements.txt
+   ```
+
+   This is not a footnote. `detect-secrets scan` with no path argument scans the files Git
+   *tracks* — an *untracked* `config.py` is invisible to it, so the gate would report "no secrets"
+   on a file that's full of them (a silent false pass, the worst kind). Staging puts the file in
+   front of the scanner. It's the same reason the explicit `detect-secrets scan config.py` in
+   Part C worked, and the same reason "secrets live in history": the moment Git knows about a file,
+   so does the gate.
+
+   To watch the gate catch both planted problems at once, restore the original booby-trapped files
+   first (you fixed them in Parts B and C) — re-copy `config.py` and `requirements.txt` from this
+   module's starter, re-stage, then run:
 
    ```bash
    ./security-scan.sh
    ```
 
-   With the bad starter files in place it should fail. With your Part B/C fixes applied, it should
+   It should **fail on both gates** — the SCA gate on the unresolvable/vulnerable dependencies and
+   the secret gate on the hardcoded key — and you should be able to point at which finding caused
+   each non-zero exit. Re-apply your Part B/C fixes (and re-stage), run it once more, and it should
    pass.
 
 2. Add a security step to your pipeline that calls it. `lab/ci-security.yml` is a provider-neutral