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

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