docs: record live runtime confirmation of alt-tab state transition (2026-07-04)

Hardware watchpoint on game_object+0x18 (runtime addr 0x2361064) fired during
active gameplay via MCP debug agent. Write at 0x4360A7 (MOV [ECX+18h], 0xB0)
inside on_deactivate_force_pause_state. Confirms existing static analysis:
- eax=0x47 (old gameplay state read just before write)
- esi=0x1c (WM_ACTIVATEAPP -- exact match to documented WM message)
- DAT_0047E578=0x47 (prev-state global saved correctly)
- game_object+0x20=0x47 (target state still 0x47, round-trip intact)
State 0xB0 (pause/deactivate) was already documented; this adds live confirmation.
The still-open symptom-2 (reset to menu on re-focus during gameplay) is not in
this state write -- it lies further along in ddraw_full_display_reinit.

Also records Item 3 watchpoint result: watchpoint on DAT_0047c488 fired at
0x40E998 (MOV [DAT_0047c488], EAX in player_cooldown_timers_tick -- the store
is in the caller, not inside compute_frame_delta_ticks_60hz_min1_clamp).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TN4Ytn3gdWRonNmHpisWQv

docs/FUNCTIONS.md

@@ -63,6 +63,7 @@ borderless-but-resizable window, not true OS fullscreen or a titled window.
 | `0x40bd30` | `ddraw_full_display_reinit` | named | **The actual heavy-lifter.** Full DirectDraw teardown/rebuild: `SetDisplayMode`, `CreateSurface` (primary+back, with retry loop on `DDERR_SURFACELOST`/`DDERR_WASSTILLDRAWING`), `Lock`, `CreatePalette`. This is the exclusive-fullscreen "recreate everything after losing the display device" path, not a lightweight `IDirectDrawSurface::Restore()`. Explains both symptoms: (1) the visible "reset" flash on alt-tab-back-in is a real full surface recreation, and (2) it only makes sense if the game requested `DDSCL_EXCLUSIVE\|DDSCL_FULLSCREEN` -- which is consistent with dgVoodoo2 presenting it as a borderless-but-resizable window rather than a normal titled window (dgVoodoo's own rendering of a wrapped exclusive-fullscreen DirectDraw app) |
 | **Conclusion, PARTIALLY REVISED (two distinct symptoms, not one)** | state machine confirmed not buggy; two separate "reset" triggers exist | -- | Internal game state survives alt-tab correctly at the state-machine level (confirmed originally, still true). Two *different* real-world symptoms both got called "resets to menu" during testing, and they have different causes: **(1) alt-tab while paused, staying away/paused too long** -- this was the pause-loop message-queue hang (see `docs/PATCHES.md` "Pause-loop hang"); confirmed fixed by `HAVOC_NOCD_PAUSEFIX_v1.EXE` (2026-07-03 test: alt-tab away while paused, return, unpause -> continues normally). **(2) alt-tab while NOT paused** -- user confirmed (2026-07-03, same session, same `HAVOC_NOCD_PAUSEFIX_v1.EXE` binary) this STILL resets to the menu on refocus, so it is a genuinely separate, still-unresolved issue -- the pause-loop fix did not touch it. Since the WM_ACTIVATEAPP handlers (`on_deactivate_force_pause_state`/`on_reactivate_restore_state`) run unconditionally on every alt-tab regardless of pause state, and we already confirmed those two functions round-trip the state variable correctly, the cause of symptom (2) is still open -- likely either in `ddraw_full_display_reinit`'s surface recreation actually failing to restore the correct visual content (not just the state int), or some other object beyond the one game-state variable we've traced so far. **Do not assume this is resolved** -- re-open investigation if picked back up |
 | **Tested** | mouse input in menu, fresh launch vs. post-alt-tab | -- | User confirmed (2026-07-03): mouse responds correctly in the menu both on fresh launch and after alt-tabbing. An earlier report of "menu doesn't respond to mouse" was transient/not reproducible -- not a real regression from the `ddraw.dll` permission fix, the `FPSLimit`/`ForceVerticalSync` tuning, or this investigation |
+| **Live-confirmed (2026-07-04)** | state transition 0x47->0xB0 on alt-tab, MCP debug agent | -- | Hardware watchpoint on `game_object+0x18` (runtime addr `0x2361064`) fired during active gameplay (state==0x47). Write at `0x4360A7` (`MOV [ECX+18h], 0xB0`) inside `on_deactivate_force_pause_state`. At stop: `eax=0x47` (old state just read), `esi=0x1c` (WM_ACTIVATEAPP - exact match), `DAT_0047E578=0x47` (prev-state global saved as expected), `game_object+0x20=0x47` (target state still 0x47). State machine round-trips correctly - confirms existing static analysis. The still-unresolved symptom-2 (reset to menu on re-focus during gameplay) is not in this state write; it lies further along in `on_reactivate_restore_state`/`ddraw_full_display_reinit`. |
 
 ## Keyboard-reassignment menu graphics bug (first genuine bug found this session)