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/20-mcp-servers-giving-the-ai-hands/README.md

@@ -330,7 +330,7 @@ That's the entire client/server loop, end to end, with zero code you wrote. Now
    > contents so I can read it."*
 
    Then open the copied file yourself and read it. (It reuses `tasks.py` and shares the same
-   `tasks.json`, so anything it changes shows up in `python cli.py list`.) The whole server is two
+   `tasks.json`, so anything it changes shows up in `python3 cli.py list`.) The whole server is two
    tools:
 
    ```python
@@ -411,14 +411,14 @@ That's the entire client/server loop, end to end, with zero code you wrote. Now
    the way you'd verify any runtime effect, by reading the *state*, not the repo:
 
    ```bash
-   python cli.py list   # the new task is there, because the server wrote the same tasks.json
+   python3 cli.py list   # the new task is there, because the server wrote the same tasks.json
    cat tasks.json       # the raw state the server changed, end to end
    ```
 
    The AI just changed real state in a real system through a tool call. Notice what you did *not*
    reach for: `git diff`. `tasks.json` is deliberately gitignored (Module 2's `.gitignore` treats it
    as generated runtime state, not source), so `git diff` stays empty here, and that's correct, not a
-   bug. The proof the task list changed is the live state (`python cli.py list` / `cat tasks.json`),
+   bug. The proof the task list changed is the live state (`python3 cli.py list` / `cat tasks.json`),
    not version control; runtime data the app owns is exactly the kind of thing you keep *out* of
    history. No copy-paste, no script you ran by hand, no pasting `tasks.json` into a chat. That's
    "hands."
@@ -477,7 +477,7 @@ The caveats, and one of them is large enough that it gets its own module.
   connected with `list_tasks` and `add_task` available.
 - You asked the AI a question and it answered by **calling a tool** against the live system, and you
   asked it to add a task and then **verified the change outside the AI** by reading the runtime state
-  (`python cli.py list` / `cat tasks.json`), not `git diff`, because `tasks.json` is deliberately
+  (`python3 cli.py list` / `cat tasks.json`), not `git diff`, because `tasks.json` is deliberately
   gitignored (Module 2).
 - You can explain the client/server model in one breath (*servers expose tools/resources/prompts;
   the client (your agentic tool) discovers and calls them on the AI's behalf*) and why "it's a