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/13-testing-in-the-ai-era/README.md

@@ -49,7 +49,7 @@ that runs a piece of your code and asserts that the result is what it should be.
 holds, the test passes silently. If it doesn't, the test fails loudly and tells you exactly which
 expectation broke.
 
-You've already been testing, by hand. Every time you ran `python cli.py list` and eyeballed the
+You've already been testing, by hand. Every time you ran `python3 cli.py list` and eyeballed the
 output, you ran a manual test: *do something, check the result looks right.* The problem with the
 manual version is the same problem copy-paste had in Module 1: it doesn't scale across files or
 across time. You can't re-run "eyeball every command" on every change, so you don't, so regressions
@@ -71,12 +71,12 @@ class TestTaskList(unittest.TestCase):
         self.assertEqual(tl.tasks[0].title, "write the tests")
 ```
 
-The whole suite runs from the project folder with a single command: `python -m unittest`
+The whole suite runs from the project folder with a single command: `python3 -m unittest`
 auto-discovers files named `test_*.py`, and `-v` prints each test name and its result. A verbose run
 looks like:
 
 ```text
-$ python -m unittest -v
+$ python3 -m unittest -v
 test_add_appends_a_task (test_tasks.TestTaskList) ... ok
 
 ----------------------------------------------------------------------
@@ -167,7 +167,7 @@ intent has to come from you.
 
 One more framing before the lab. A test file just sitting in your repo is useful when you remember to
 run it; like the manual eyeball check, you eventually won't. The full payoff comes in
-**Module 14**, where Continuous Integration runs this exact `python -m unittest` command
+**Module 14**, where Continuous Integration runs this exact `python3 -m unittest` command
 automatically on every push, so a regression can't reach `main` without something going red first.
 
 That's why this module comes immediately before CI: **tests are the content CI runs.** You can't
@@ -256,7 +256,7 @@ Do this once yourself so the tool isn't magic. From inside your working copy of
 2. Run it:
 
    ```bash
-   python -m unittest -v
+   python3 -m unittest -v
    ```
 
    You should see one test, and `OK`. That's the entire mechanism. Everything else is more of these.
@@ -286,7 +286,7 @@ Do this once yourself so the tool isn't magic. From inside your working copy of
 5. Run the suite:
 
    ```bash
-   python -m unittest -v
+   python3 -m unittest -v
    ```
 
    At least one `pending_count` test should **FAIL**, with something like
@@ -310,8 +310,8 @@ Do this once yourself so the tool isn't magic. From inside your working copy of
        return len(self.pending())
    ```
 
-   Re-run `python -m unittest -v`; green. Confirm the app agrees:
-   `python cli.py add a && python cli.py add b && python cli.py done 0 && python cli.py count`
+   Re-run `python3 -m unittest -v`; green. Confirm the app agrees:
+   `python3 cli.py add a && python3 cli.py add b && python3 cli.py done 0 && python3 cli.py count`
    should report **1 task(s) pending**.
 
    > Using your own app from earlier modules instead? If your `count` command was already correct,
@@ -365,7 +365,7 @@ The honest limits, because a green suite invites overconfidence:
 
 **You're done when:**
 
-- You can run `python -m unittest -v` in your `tasks-app` and see your own tests pass.
+- You can run `python3 -m unittest -v` in your `tasks-app` and see your own tests pass.
 - You watched an intent-encoding test **fail**, traced it to the real `pending_count` bug, fixed the
   *code*, and watched it pass.
 - You can articulate, in your own words, the difference between a test that asserts current behavior