[Bug]: Client connects to websocket but lands on a different zone (gcp-zone) than other clients

### Problem description

Let's suppose we have a chat application where clients connects to, pretty much like the ChatApp example [here](https://docs.deno.com/runtime/tutorials/chat_app/).

Everything is working fine and my client implementation also supports reconnects and looks at a ping messaage to detect network issues.

The problem starts when a new client connects and its request is handled on a different gcp in which case the client is alone and can't reach the other clients.

Is this the way it is supposed to work?
Is there anyway around it?

Thanks.

### Steps to reproduce

1. Run the chat application connecting with a client
2. Run the chat application on another network until its request is handled in another gcp-zone (is may help to use a vpn on the this client to force deno deploy to start a new gcp on another zone)

The two clients are isolated and cannot exchange messages.

### Expected behavior

The clients should be able to exchange messages

### Environment

_No response_

### Possible solution

I would like to have the ability to tell deno deploy to not to run start another gcp.
Alternatively I'd need a way to have each gcp able to communicate with the others so that information on connected clients can be exchanged

### Additional context

_No response_

The payload names the Deno Deploy chat application tutorial but no repository file, test, or implementation entry point. Start by reproducing the chat application across different GCP zones and establish whether WebSocket client state is zone-local. Done should include documented platform behavior and an agreed supported approach for cross-zone client communication or session routing.

Written by the indexing model from the issue text.