fix(window): coalesce activation events through classic pending slots

[benletchford]

Fixes #597.

What changed

• Model the Window Manager's CurActivate and CurDeactive low-memory globals as the two replaceable pending activation slots.
• Clear each slot when its event is delivered.
• Route window and dialog activation generation through the shared slot-aware path.
• Activate a window created frontmost with behind = (WindowPtr)-1 even when it is initially invisible, matching classic Window Manager behavior.
• Add regression coverage for rapid superseding transitions and invisible frontmost creation.

Root cause

Activation events bypass the classic Operating System event queue, but the HLE accumulated them in an unbounded FIFO. It also skipped activation when a frontmost window was created invisible. A sequence of rapid window changes could therefore deliver a superseded deactivation event after an application had released and reused the target window's refCon storage, causing guest dispatch through stale data.

Impact

Applications that construct several frontmost windows before polling events now observe the latest pending activation/deactivation pair and the documented active state for invisible frontmost windows. Civilization II proceeds through world generation instead of jumping through a stale callback.

Validation

• cargo fmt --all -- --check
• cargo test pending_activation --lib
• cargo test invisible_frontmost_new_window --lib
• Authentic Civilization II 68K demo automation proceeds past world generation to tick 15,372 and remains responsive after input through tick 16,278.

[benletchford]

Superseded by #599, which contains the identical patch and is ready for review with green CI.