fix: resolve navigation hang on Windows when using intercept with object mock

[winst0niuss]

Fixes the Windows navigation hang diagnosed in #2775.

What the debug logs showed

Using the taiko:intercept logging from #2775, captured this pattern for the second navigation:

requestPaused url=https://localhost/employees/2/address    ✓ CDP event fired
matched interceptor ...                                    ✓ interceptor found
calling fulfillRequest (object) responseCode=200           ✓ called, no error
--- silence for 60 seconds ---
Navigation took more than 60000ms                          ✗ timeout

Fetch.fulfillRequest completes without error, so the hang is not a network or interceptor issue.

Root cause

handleNavigation() in pageHandler.js awaits a responsePromise that resolves only when Network.responseReceived fires with a matching requestId. On Windows, after Fetch.fulfillRequest, Chrome sometimes:

1. Skips Network.responseReceived entirely — responsePromise never resolves
2. Skips frameStoppedLoading — a pending frameEvent promise in waitForNavigation's Promise.all() never resolves

Either way, navigation times out after 60 seconds.

The first navigation (/employees/1/address) avoids the race; the second hits it because Chrome's internal state is slightly different after the first completed navigation.

Fix

fetchHandler.js — after fulfillRequest resolves for a Document resource, emit two synthetic events:

• interceptedNavigationResponse with the URL and response details — unblocks responsePromise in handleNavigation via URL matching (avoids relying on p.networkId which is optional and may be undefined)
• navigationFulfilledByIntercept with p.frameId — signals pageHandler to resolve any pending frame promises

pageHandler.js — two additions:

• handleNavigation now also listens for interceptedNavigationResponse and resolves responsePromise when the URL matches the navigation target
• Module-level listener for navigationFulfilledByIntercept that calls resolveFrameEvent and resolveFrameNavigationEvent, allowing waitForNavigation to proceed to the document.readyState check

Also included

• Windows CI: retry wrappers restored (removed temporarily during diagnosis to expose the failure signal, now restored for infrastructure flakiness unrelated to this fix); added on_retry_command: taskkill /F /IM chrome.exe /T for unit tests to kill lingering Chrome processes between attempts and prevent cascade failures
• Unit test for handleNavigation updated to reflect the new interceptedNavigationResponse listener

Checks

Actions Run: View GitHub Actions Run

[gaugebot]

@winst0niuss Thank you for contributing to taiko. Your pull request has been labeled as a release candidate 🎉🎉.

Merging this PR will trigger a release.

Please bump up the version as part of this PR.

Instructions to bump the version can found at CONTRIBUTING.md

If the CONTRIBUTING.md file does not exist or does not include instructions about bumping up the version, please looks previous commits in git history to see what changes need to be done.

[winst0niuss]

The failure in Unit tests - windows-latest - 24 is unrelated to this PR. The process crashed mid-run with exit code 3221226505 (0xC0000409 — STATUS_STACK_BUFFER_OVERRUN), which is a Windows OS-level crash, not a test assertion failure.
Re-run should resolve it.

[zabil]

@winst0niuss looks like windows tests as still flaky?

[winst0niuss]

Tests are still flaky. I'm looking into it.

[winst0niuss]

Windows write tests were stabilized in a dedicated branch (winst0niuss#3) and verified over 10 CI runs with no test-related failures. The fix is now in master: commit 479f7de.

[winst0niuss]

@zabil, re-run tests, pls

[winst0niuss]

@zabil, all tests are green.
check pls