RBE971 drops offline & reboots continually, ready for return

Migrated from Eero Gen 1 (EOL) about 4 days ago and the Orbi system is completely unstable. Have managed at best ~8hrs of up time.

I set up Orbi to use same SSID that includes Pixel 5,6,7,8 phones, a couple of different generation Lenovo laptops, large Sonos topology, a couple RPi/IoT devices (PiHole/HomeAssistant), Arlo cameras, Qolsys alarm panel, a couple Rokus, Synology NAS & LG TV and Yamaha receiver.

Tried disconnecting satellites and creating a new SSID with only phones & laptops connected with same result. Tried new cable modem with same result. Restored Eero network and it's back to a workhorse-stable network with the new modem.

Config:

• Xfinity 1Gb/s service with Arris S33v2 (was Motorola MB8600) connected via .5m CAT7, Xfinity has checked line and modem provisioning. Get ~300Mb/s with Eero & 1.2Gb/s with Orbi speed tests from the router apps.
• RBE971 is running v9.10.02
• Clients are Lenovo laptops with various gen wireless a,b,g/n/ax, phones are 4 generations of Pixel running Android 10-14

Symptoms:

Wifi and wired networks drop offline, sometimes every couple of minutes & sometimes every couple of hours. No lights on router & cable modem is still online @  Xfinity.com and its WAN ethernet port still shows a link light. If I don't power cycle, eventually (after 15min or so) router will reboot, flashes white then comes back online. In addition to the above, when satellites were connected (wired and wireless backhaul) the same thing would happen at the router but satellites would also occasionally disconnect, reboot & resync before router eventually reboots.

This doesn't feel like a fully baked product, but if there is some known issue/workaround I'm willing to give it one more try before it goes back -- but my return window clock is running and I'm out of patience. This is not surprising with draft-spec. 1st-to-market products so it's kind of on me for taking the plunge. 802.11ax is mature and tested and I don't really need 802.11be so I guess that's where I'm headed.

If I had to guess, some unhandled exception, error threshold, or race condition is causing kernel lockups and watchdog timer expiration reboots. There is no way to save a debug.htm log before the reboots occur, so I'm skeptical that this is easy to root cause without a JTAG debugger or instrumented firmware.