Use python3 as the canonical command name course-wide (#104)

Most current systems (default Debian/Ubuntu, recent macOS) install Python
only as `python3`, with no bare `python` on PATH, so learners who copied
`python cli.py ...` into their host shell hit "command not found".

Convert host-shell `python <cmd>` -> `python3 <cmd>` across module/lab
READMEs, lab `.py` docstrings & usage strings, blog posts, lab prompt and
instruction files, the M04 verify.sh message, and the M10/M24 lab patches.
Module 01's convention note (and its blog/02 mirror) is rewritten so
`python3` is canonical and `python` is the documented fallback.

Stop-lines respected: Docker image tags (`python:3.12-slim`), `.venv/.../python`
and `...\.venv\Scripts\python.exe` paths, the M20 `"command": "python"`
teaching example and surrounding venv prose, container-internal invocations
(M16/M18 Dockerfiles, M16 README `docker run` examples), and CI-workflow
`run:` steps fed by `actions/setup-python` / `image: python:3.12` are left
as `python` on purpose.

pip was left out of scope: most occurrences are prose or CI/container-internal,
and `pip3` does not fix the PEP 668 externally-managed-environment refusal that
the course already addresses with venvs. The M01 note is worded to stay
consistent with bare `pip` (use whichever pip pairs with your Python).

Build (tools/build_wiki.py) and tools/check.sh both pass.

Closes #104

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

modules/14-continuous-integration/README.md

@@ -78,7 +78,7 @@ Almost every CI configuration, on every forge, is the same four moves:
 4. **Run the checks**: lint, then test. Any check that exits non-zero fails the whole run.
 
 That last point is the load-bearing one. CI's entire enforcement mechanism is the **exit code**.
-Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `python -m
+Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `python3 -m
 unittest` exits non-zero if a test fails. `ruff check` exits non-zero if it finds a lint problem. CI runs your
 commands and watches those exit codes; one failure turns the run red. You're not learning a new
 testing system; you're wiring the tools you already have to a trigger.
@@ -154,7 +154,7 @@ When CI goes red, the skill is triage, and it's fast once you know the shape:
 3. **Read that step's log.** It's the same output the tool prints in your terminal: a failing
    `unittest` assertion, a `ruff` finding with a file and line number. CI didn't invent a new error
    format; it's showing you the command's own output.
-4. **Reproduce it locally.** The same command from the failed step (`python -m unittest` or
+4. **Reproduce it locally.** The same command from the failed step (`python3 -m unittest` or
    `ruff check .`) fails the same way on your own machine, because CI ran exactly that command. That
    reproducibility is the point: fix locally, confirm green locally, push again.
 
@@ -254,7 +254,7 @@ your machine first.
    that CI is nothing more than these same two commands is what makes the rest of the module click.
 
    ```bash
-   python -m unittest   # should report all tests passing
+   python3 -m unittest   # should report all tests passing
    ruff check .         # should report no issues (or fix what it flags)
    ```
 
@@ -325,7 +325,7 @@ and watch CI stop it.
    `git restore` (Module 12). What the agent runs looks like:
 
    ```bash
-   python -m unittest          # fails locally too: same command, same failure
+   python3 -m unittest          # fails locally too: same command, same failure
    git revert --no-edit HEAD   # new commit that undoes "Simplify pending()" (Module 12)
    git push                    # CI re-runs on the fixed code and goes green again
    ```

modules/14-continuous-integration/lab/start/README.md

@@ -15,11 +15,11 @@ This is the running example for **Module 1** (where you feel the copy-paste prob
 ## Run it
 
 ```bash
-python cli.py add "read module 1"
-python cli.py add "set up my editor"
-python cli.py list
-python cli.py done 0
-python cli.py list
+python3 cli.py add "read module 1"
+python3 cli.py add "set up my editor"
+python3 cli.py list
+python3 cli.py done 0
+python3 cli.py list
 ```
 
 Requires Python 3.10+ (it uses `list[Task]` style type hints). No third-party packages.

modules/14-continuous-integration/lab/start/cli.py

@@ -1,8 +1,8 @@
 """Tiny command-line front end for the demo task app.
 
 Run it:
-    python cli.py add "write the lesson"
-    python cli.py list
+    python3 cli.py add "write the lesson"
+    python3 cli.py list
 
 State is kept in tasks.json next to this file. It's intentionally minimal; the point of this app
 is to be a realistic-but-small thing you change with an AI, not a product.
@@ -31,7 +31,7 @@ def save(tlist: TaskList) -> None:
 def main(argv: list[str]) -> int:
     tlist = load()
     if not argv:
-        print("usage: python cli.py [add <title> | list | done <index> | count | delete <index>]")
+        print("usage: python3 cli.py [add <title> | list | done <index> | count | delete <index>]")
         return 1
 
     command = argv[0]

modules/14-continuous-integration/lab/test_tasks.py

@@ -2,7 +2,7 @@
 
 Reproduced here so this module's lab is self-contained: if you already wrote tests in Module 13,
 use those instead. Standard-library `unittest`, exactly like Module 13, nothing to install.
-Run locally with `python -m unittest` from the project folder. CI runs exactly this.
+Run locally with `python3 -m unittest` from the project folder. CI runs exactly this.
 """
 
 import unittest