The client-side `BrowserContext._onRequestFailed` handler in
`playwright-core` does not resolve the corresponding
`Response._finishedPromise`, while `_onRequestFinished` does. When
Chromium fires `Network.loadingFailed` for a request that already
received a response — e.g. an RSC response that was delivered to the
response buffer but is no longer needed because a soft navigation has
already committed — the server-side `_finishedPromise` is resolved
correctly (in `chromium/crNetworkManager._onLoadingFailed`), but the
client side is never told. Any caller of `response.finished()` on
such a response hangs indefinitely, surfacing in tests as a 60s Jest
timeout with no clear stack trace.

This is the root cause of intermittent timeouts in router-act-using
tests.

The patch mirrors the resolve step from `_onRequestFinished`: look up
the response via the existing async `request.response()` RPC and
fire-and-forget `resolve(null)` on its `_finishedPromise`. `catch`
is a no-op so a tearing-down context doesn't produce an unhandled
rejection.

Verified empirically against workflow run
https://github.com/vercel/next.js/actions/runs/25760869258, which
flake-detected all 40 router-act consumers (each 3 times) with
diagnostic logging enabled. One `Network.loadingFailed canceled=true`
event fired during the run (the canonical bug scenario: an outer
`act` releasing a child `block: true` response that Chrome canceled
mid-flight; see
https://github.com/vercel/next.js/actions/runs/25760869258/job/75669131568)
— pre-patch this would have hung until Jest's 60s test timeout
fired, post-patch `response.finished()` resolved in 1ms. Alongside
~4000 normal resolutions, with zero `wait-browser-finished` hangs
and zero router-act-related test failures.

This is a stop-gap until the router-act rewrite in #90959 lands, which
replaces Playwright's `route.fulfill` + `response.finished()` flow
with a browser-side `fetch` interception and removes the dependency
on this Playwright code path entirely. The patch can be dropped at
that point.