Function hasInFlightResolution

Whether a resolve is genuinely in flight for combat right now — i.e. at least one action is currently inside _resolveOneAction (most commonly: blocked on an interactive prompt such as a target picker or burst placement). This closes a blind spot getDueUnresolvedActions() alone has: _processCombatSteps's intermediate bmsResolving write sweeps the due action out of the live document's down 0 before resolve() (which contains the interactive-prompt await chain) ever runs, so a caller that only reads the live document sees zero due-unresolved actions during a window where a resolution is genuinely still pending — previously making the advance-guard/UI look idle while a player prompt was actually up, and inviting a second advance click into the lock-conflict path (see _tryAcquireAdvanceLock's doc comment).

Callers that need "is anything happening right now" (the advance guard in advanceTracker()/advanceToNextResolution(), and the tracker UI's hasUnresolvedDue button-mode computation) must check both this AND getDueUnresolvedActions().length — neither alone is sufficient. This function catches the swept-but-still-resolving window; getDueUnresolvedActions() catches the durable due-but-not-yet-claimed window (e.g. right after an aborted prompt released its claim, or after a GM browser refresh left an action at resolutionTime: 0, resolved: false with no pass attached at all).