docs(course): replace Scala bridges with general programming in 06–11, method, reference

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

course/09-wiring-it-together.md

@@ -91,9 +91,9 @@ There's one more thing: `scan` emits only *new* accumulators, never the initial
 states(seed, actions) = startWith(scan(actions, update, newGame(seed)), newGame(seed))
 ```
 
-> **From Scala:** `scan` is `scanLeft` on a list that hasn't happened yet. `List(a1, a2).scanLeft(s0)(update)` gives `List(s0, s1, s2)` *including* `s0`; our `startWith(scan(…), s0)` is how we get the same "include the start" behaviour.
+> **From everyday programming:** in the classic game loop, `while (running) { input(); update(); render(); }`, the game state is one variable that each iteration overwrites, and the sequence of states exists only as the history of that variable. `startWith(scan(…), s0)` gives you that history as a value: `s0, s1, s2, …`, one state per action, the way a bank statement lists the opening balance followed by the balance after each transaction. `scan` alone is the list of balances *after* each transaction; `startWith` adds the opening balance in front.
 
-You've seen this exact shape elsewhere: **Redux** reducers are `(state, action) → state` folded over a stream of dispatched actions, and **Elm**'s `update : Msg -> Model -> Model` is the same fold run by the Elm runtime. (The argument order differs per library; the idea doesn't.)
+You may have seen this exact shape elsewhere: **Redux** reducers are `(state, action) → state` folded over a stream of dispatched actions, and **Elm**'s `update : Msg -> Model -> Model` is the same fold run by the Elm runtime. (The argument order differs per library; the idea doesn't.)
 
 ### 4. From states to drawings, and `main`