CF Pages WebSocket-only Worker intermittently fails with "Network connection lost" and "hung" after returning 101

## Description

I am experiencing a runtime-level issue with a minimal Cloudflare Worker that only establishes a WebSocket connection and returns a `101 Switching Protocols` response.

The issue can be reproduced with a minimal Worker containing no application-level networking logic, no streaming logic, and no additional asynchronous processing.

The primary error is:

```text
Error: Network connection lost.
```

I also intermittently receive:

```text
The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.
```

The problem occurs even with the minimal reproduction below.

## Environment

* Cloudflare Workers / Pages
* Compatibility date: `2026-09-08`
* Wrangler: `4.90.0`
* Runtime: current September 2026 runtime
* Reproduces intermittently across multiple test locations
* No application-level networking logic is involved in the reproduction below

## Minimal reproduction

```javascript
export default {
async fetch(request, env, ctx) {
if (request.headers.get("Upgrade") !== "websocket") {
return new Response("WebSocket Runtime Minimal Test", {
status: 200,
});
}

console.log("[MINIMAL] fetch start");

const pair = new WebSocketPair();
const ws = pair[0];
const client = pair[1];

ws.accept();

console.log("[MINIMAL] ws.accept completed");
console.log("[MINIMAL] returning 101");

return new Response(null, {
status: 101,
webSocket: client,
});
},
};
```

## Observed behavior

The Worker consistently reaches:

```text
[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101
```

The `101` response is returned, but the runtime may subsequently report:

```text
Error: Network connection lost.
```
or:

```text
Error: The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.
```

In some cases the same request produces the `hung` error multiple times, while other requests produce `Network connection lost`.

## Important observation

This reproduction contains no application-level networking or streaming implementation.

The Worker does only three relevant operations:

1. Create a `WebSocketPair`
2. Call `accept()`
3. Return a `101` response containing the WebSocket

Therefore, the failure appears to occur after the WebSocket upgrade rather than being caused by application-level data processing.

## Example logs

```text
[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101

X [ERROR] Error: Network connection lost.
```

Another occurrence:

```text
[MINIMAL] fetch start
[MINIMAL] ws.accept completed
[MINIMAL] returning 101

X [ERROR] Error: The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.
```

The behavior is intermittent rather than occurring on every connection.

## Expected behavior

After the Worker returns:

```text
HTTP 101 Switching Protocols
```

the WebSocket connection should remain valid until the client or server closes it.

A minimal WebSocket Worker should not produce a runtime-level `Network connection lost` or `hung` error when there is no additional application logic involved.

## Actual behavior

The WebSocket upgrade succeeds from the Worker application's perspective:

```text
ws.accept completed
returning 101
```

but the Workers runtime subsequently reports either:

```text
Network connection lost
```

or:

```text
The Workers runtime canceled this request because it detected that your Worker's code had hung and would never generate a response.
```

## Additional observation

The issue appears independent of the application logic.

I initially investigated the problem as an application-level issue, but reducing the Worker to the minimal WebSocket implementation above still reproduces the runtime errors.

This makes me suspect a problem in the WebSocket/runtime lifecycle handling rather than in the Worker application's data-processing logic.

Could you please confirm whether there is a known issue with the current Workers runtime concerning WebSocket connections that have successfully returned `101`, particularly cases where the runtime subsequently reports `Network connection lost` or incorrectly classifies the request as a hung Worker?

If this is a known runtime regression, any information about the affected runtime versions, compatibility-date behavior, or an expected fix would be appreciated.

Thank you.

Start by reproducing the minimal JavaScript Worker with Wrangler 4.90.0 and compatibility date 2026-09-08. Observe the lifecycle after ws.accept and the 101 response, focusing on when the Network connection lost or hung errors appear. Done means the minimal WebSocket remains valid after the upgrade without either runtime error.

Written by the indexing model from the issue text.