[Bug]deck.gl will not load during first render of suspense fallback or loading.tsx within nextjs

Description

This is an odd one, but I have reproduction. If you are using deck.gl component as a fallback to a suspense boundary, or within next.js's native loading.tsx paradigm the first hard load of the page deck gl simply will not attempt to load itself. I was not able to find any logging or reason for this. However, as soon as the page fully loads and all the suspense boundaries resolve, deck gl will in fact load. There appears to be some sort of loading happening in the background that attaches itself to a global context because after that first full resolution (or maybe it determines some sort of ssr/suspense has "finalized"?), any soft-navigation back to the previous view, and deck gl appearing again in the fallback component will, this time, render correctly. Very odd. And hugely blocking for me and my team.

Expected Behavior

I would expect to be able to use deck.gl as a fallback component within a suspense boundary.

Steps to Reproduce

I have created a code sandbox:

https://codesandbox.io/p/devbox/charming-kalam-jj4ffr

If you run this sandbox, I have created a RSC homepage with an artificial 4 second delay. During the first load you will notice that deck gl will not initialize despite it being in the fallback component. Navigating away from the page using the Link to the /second page I render on the homepage, and then navigating back to the homepage using the link on the /second page you will see the component will load for 4 seconds again, and again it will load the fallback but this time deckgl will fully render and function as normal.

Environment

• Framework version: Deck.gl 9.1.8
• Browser: Chrome 134.0.6998.89
• OS: Mac OS 13.2.1

Edit: Upon more testing, it seems deck.gl will not go through any form of initialization before window.onload is called (not 100% but it seems to time up right in spite of any delay added to the loading process) and nextjs does not cause a window.onload function to fire until all loading/suspense boundaries are resolved. Is there anyway to bypass this behavior for deck.gl?

Start with the linked CodeSandbox reproduction and compare the initial hard load with the soft-navigation case. Investigate deck.gl initialization relative to window.onload and Next.js Suspense/loading.tsx behavior; done when deck.gl initializes and renders during the first fallback display.