docs(lessons): Sequence vs outermost Phase differs bullet (02, 03); lesson 01 cross-reference

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

course/02-action-queue/lesson.md

@@ -273,7 +273,7 @@ function react(world: World, events: Event[]): void {
 }
 ```
 
-Two things to notice. The call stack *is* the depth-first order: `perform` calls `react`, which calls `perform` for a nested action, and the outer loop only continues once that returns. And `run_sequence` / `runSequence` is a single entry point for every player action. That is where Module 3 will add death processing, "once the outermost Phase ends".
+Two things to notice. The call stack *is* the depth-first order: `perform` calls `react`, which calls `perform` for a nested action, and the outer loop only continues once that returns. And `run_sequence` / `runSequence` is a single entry point for every player action. That is where Module 3 will add death processing. The course treats a player action's whole Sequence as one outermost Phase, so the end of `run_sequence` is where "the outermost Phase ends" ([Advanced rulebook](https://hearthstone.wiki.gg/wiki/Advanced_rulebook)); Module 3 says how the real game differs.
 
 This is not the queue you may know from other games. Robert Nystrom's *Event Queue* chapter, the classic description of the general pattern, says "You only need a queue when you want to decouple something in time" and offers "A common rule to avoid this is to avoid sending events from within code that's handling one" ([*Game Programming Patterns*, Event Queue](https://gameprogrammingpatterns.com/event-queue.html)). A card game breaks that rule on purpose: reactions cause reactions. It survives by fixing the order explicitly (order of play) and the depth (finish the child before the sibling).