docs(course): consistency pass

- m04: F# mulberry32 hints and skeleton route * and + through uint64 helpers;
  new 'F# in the browser' note on the Fable uint32 trap
- m01-m05: 'About test names' notes like m06-m11; m00 explains JS vs Scala/F# titles
- m00/m09: first build-web.sh run restores Fable; m09 JS file list (main.js is given)

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

course/02-the-game-as-data.md

@@ -249,6 +249,8 @@ Cases with no data are constants; a case with data (`Turn`) is a function that b
 
 ## Exercises
 
+> **About test names.** The test titles quoted under "Test"/"Tests" are the JavaScript ones; the JS runner prints them with the module in front (`m02 opposite is its own inverse`). The Scala and F# suites test the same things, but where JS checks a function you write (`point`, `Action`) they check the declarations you were given instead: `Point holds its coordinates`, `Action.Turn carries the direction` (F#: `Action Turn carries the direction`), `the other Actions are distinct constants`. Failing tests are reported by name when you run the module's tests; to read all titles, open `scala/test/M02Model.test.scala` or `fsharp/tests/M02Model.fs`. Fixture-based tests have the same case names in every track (JS `m02 delta: up`, Scala/F# `delta: up`; the `pointEquals` cases are labelled `pointEquals (case-class ==)` in Scala and `pointEquals (record =)` in F#).
+
 ### Exercise 2.0 — Your own design (paper)
 
 Complete the design questions at the top of "Concepts" before reading the canonical model. Afterwards, write three sentences: one thing your design did better or differently, one thing the canonical model does that you had not thought of, and one trade-off you would make differently in a bigger game. Keep the sheet; Module 11 asks you to do this again for Pong.