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

Co-Authored-By: Claude Opus 5.5 <[email protected]>

course/06-rendering-as-data.md

@@ -91,7 +91,7 @@ type Scene = Shape list
 let scene : Scene = [ Rect (0, 0, 400, 400, "#111111"); Text (6, 18, "hello", "#ffffff", 16, "left") ]
 ```
 
-> **From Scala:** a `Scene` is a `List[Shape]` where `Shape` is a sum type with two cases. You would never think of a `List[Shape]` as "doing" anything; it just sits there. That is the whole point. In JS you get the same thing with an array of tagged objects; nothing stops you from mutating it, which is why the tests freeze the inputs and why you keep using the habits from Module 1.
+> **From everyday programming:** think of a shopping list, or the list of rows a SQL query returns. You would never think of such a list as "doing" anything; it just sits there until someone reads it. A `Scene` is the same kind of thing: a list of shapes, each of which is one of exactly two kinds (a rectangle or a text). That is the whole point. In the Scala and F# tracks the compiler keeps the list and its shapes immutable; in JS you build it from arrays of tagged objects, and nothing stops you from mutating them, which is why the tests freeze the inputs and why you keep using the habits from Module 1.
 
 Notice what is *not* in a shape: no canvas, no context, no "current fill colour". In the stateful version, `ctx.fillStyle = color` sets a hidden variable that the next `fillRect` reads. In a shape, the colour travels *with* the rectangle. Every shape is complete on its own. That is the same move you made with `GameState` in Module 2: instead of state that lives somewhere and changes, a value that contains everything.