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/05-commit-the-ai-config/README.md

@@ -48,7 +48,7 @@ committed instructions file from the repo, and you control what's in it.**
 > content if so. The principle outlives any one vendor's filename.
 
 Without this file, you re-explain your project every session: "we use 4-space indent," "run the tests
-with `python -m unittest` before you say you're done," "don't touch the generated `tasks.json`." You say it,
+with `python3 -m unittest` before you say you're done," "don't touch the generated `tasks.json`." You say it,
 the AI complies, the session ends, the memory evaporates (Module 1's second seam), and tomorrow you
 say it all again. The instructions file is where that knowledge stops being something you retype and
 becomes something the project *carries*.
@@ -62,7 +62,7 @@ a briefing for an agent that will edit this code. Keep it to what changes the AI
   uses. "Core logic lives in `tasks.py`; the CLI front end is `cli.py`; state persists to
   `tasks.json`."
 - **Build and test commands**: the exact commands, copy-pasteable. "Run the app with
-  `python cli.py <command>`. Run tests with `python -m unittest`. Don't claim a change works until
+  `python3 cli.py <command>`. Run tests with `python3 -m unittest`. Don't claim a change works until
   the tests pass." This single line stops the AI from inventing a test runner you don't use.
 - **Coding standards**: formatting, typing, error handling, the libraries you do and don't want.
   "Use the standard library only, no third-party packages. Type-hint public functions."
@@ -83,7 +83,7 @@ useful for personal preferences, but it's the wrong home for project knowledge,
 lives: on *your* laptop, invisible to everyone else.
 
 Picture a two-person project with no committed instructions file. You've trained your local setup to
-run `python -m unittest` and avoid `tasks.json`. Your teammate's setup hasn't, so their agent reformats whole files
+run `python3 -m unittest` and avoid `tasks.json`. Your teammate's setup hasn't, so their agent reformats whole files
 and hand-edits the generated JSON. You're both "using AI on the same repo," but you're getting
 different behavior, and neither of you can see the other's configuration. That's **drift**: the same
 codebase, diverging because the rules live in two heads instead of one file.
@@ -215,7 +215,7 @@ editor-integrated AI (Module 4) for the part where the AI obeys the file.
 - The `tasks-app` repo from Module 2 (already a Git repo with some history).
 - Your agentic coding tool from Module 4, and knowledge of which filename it reads for repo-level
   instructions (check its docs; see the note in *Key concepts*).
-- Optionally, a test command for the AI to honor; Python's built-in `python -m unittest` works with
+- Optionally, a test command for the AI to honor; Python's built-in `python3 -m unittest` works with
   nothing to install (you'll write a real suite in Module 13; until then it simply reports no tests).
 
 ### Part A: Write the instructions file and let the AI commit the config
@@ -321,7 +321,7 @@ Be honest about what a committed instructions file does and doesn't buy you:
 - **Bloat kills it.** A 300-line instructions file is read the way *you* read a 300-line terms-of-
   service: not really. Every line you add dilutes the rest. Keep it to what actually changes behavior,
   and prune lines the model already honors without being told.
-- **Stale instructions are worse than none.** A file that says "run the tests with `python -m
+- **Stale instructions are worse than none.** A file that says "run the tests with `python3 -m
   unittest`" after you've switched to a different runner will actively misdirect the AI. The file is
   code-adjacent: it has to be maintained like code, and reviewed like code. That's exactly why
   committing it (so changes are