fix: race condition in client.listen memory leak

[stipsan]

While implementing client.live.events() the code underlying client.listen was used and a new race condition were discovered that leads to instances of new EventSource that should've been closed, but are instead left open.
In client.live.events() the race condition were pretty easy to reproduce, all you need is a React application in StrictMode and a useEffect implementation:

import {createClient} from '@sanity/client'

const client = createClient({
  projectId: 'pv8y60vp',
  dataset: 'production',
  useCdn: true,
  apiVersion: 'X',
})

export default function Example() {
  useEffect(() => {
    const subscription = client.live.events().subscribe({
      next: (event) => {
        console.log({event})
      },
      error: (err) => console.error(err),
    })
    return () => {
      subscription.unsubscribe()
    }
  }, [])

  return null
}

Inspecting the browser devtools networks tab would reveal two instances of an EventSource, where it should've been 1.

Since client.live.events() is built upon client.listen() I assumed the same reproduction would work there as well, but it doesn't:

import {createClient} from '@sanity/client'

const client = createClient({
  projectId: 'pv8y60vp',
  dataset: 'production',
  useCdn: true,
  apiVersion: 'X',
})

export default function Example() {
  useEffect(() => {
    const query = '*[_type == "$type"]'
    const params = {type: 'post'}
    const subscription = client.listen({query, params}).subscribe({
      next: (event) => {
        console.log({event})
      },
      error: (err) => console.error(err),
    })
    return () => {
      subscription.unsubscribe()
    }
  }, [])

  return null
}

It turns out the reason it was so easily, and consistently, reproduced in client.live.events(), but not for client.listen(), turned out to be that client.listen always lazy imports @sanity/eventsource, while client.live.events() only does so if there's no native globalThis.EventSource available. Since dynamic ESM imports are resolved at the same time, no matter what call site or call order, it's possible to consistently reproduce the race condition by waiting with calling .unsubscribe() until after the dynamic import is resolved:

     return () => {
-      subscription.unsubscribe()
+      import('@sanity/eventsource').then(() => subscription.unsubscribe())
     }

I tried to capture this in a unit test but it was too flaky and I eventually gave up.
Instead I have a Codesandbox instance that demonstrates it:

And here's the same sandbox but demonstrating that the fix works.

[rexxars]

This is a great find. Had to double and triple read the flow here to understand, so for posterity:

1. getEventSource() does its async module load, checks if unsubscribed - which at this point it is not.
2. Creates an ES with listeners, synchronously. Returns.
3. The event loop yields, because it's an async fn. This is the race condition that was unaccounted for.
4. open() receives the EventSource, but incorrectly assumed that we could not have unsubscribed between the module load and now.