Don't let the attract timer hijack an in-flight menu fade (#723)

Pressing start on the splash screen in the last moments before the demo
timeout could play the enter chime and then drop into the demo reel with
no music: the attract timer (gMenuTimingCounter >= 0x12D) fired while the
press-start fade was in flight and overwrote gMenuFadeType to the demo
value, so the fade completed as a demo entry. Vanilla bug; roughly a
0.7-second window every attract cycle.

Only arm the demo when no fade is in flight. A natural timeout (idle, no
fade running) behaves exactly as before.

Play-verified: start pressed repeatedly around the timeout boundary always
lands in the main menu with music; the demo reel still plays when idle.

1 files changed, 5 insertions, 1 deletions

diff --git a/src/menu_items.c b/src/menu_items.c
index 375258be1..243f1aab0 100644
--- a/src/menu_items.c
+++ b/src/menu_items.c
@@ -2847,7 +2847,11 @@ void func_80095574(void) {
     if (gMenuTimingCounter == DEBUG_MENU_DEBUG_MODE) {
         play_sound2(SOUND_INTRO_WELCOME);
     }
-    if (gMenuTimingCounter >= 0x12D) {
+    // Don't arm the demo reel while another fade is in flight: pressing start
+    // in the last moments before the attract timeout let this overwrite the
+    // press-start fade's gMenuFadeType mid-fade, hijacking it into the demo
+    // with the menu music already faded out. (Vanilla bug.)
+    if (gMenuTimingCounter >= 0x12D && is_screen_being_faded() == 0) {
         func_8009E230();
         func_800CA0A0();
     }