OK, so I was able to track down the problem…
It was not a power issue, nor a bad connection on the card. I was able to duplicate the problem because it became less random and nearly permanent, so I pulled the ESP board and powered it up via USB and experienced the same issue.
The network that the ESP is connecting to is an ASUS AiMesh with a main router and one AiMesh node. The node was in a state which was causing a divide by zero error in the EspressIf WIFI module. Rebooting the main Asus router did not fix anything, but rebooting the node has temporarily fixed the issue. I realize this sounds unlikely, but my testing was exhaustive and I’m convinced it is correct. I believe the randomness of the issue was because whenever the ESP connected to the main router, it booted up fine, but when it connected to the node, it failed.
So, the bug is likely in the EspressIf WIFI code but because of where it was happening in the boot process, FluidNC was treating it as a config error and switching to panic mode, which loads a generic config, triggers an ALARM that cannot be reset, and insists the config error be addressed. Huge red herring. Specifically, the code can be found in the ../Machine/MachineConfig.cpp in the FluidNC source, but I noticed that file has changed since v3.9.4, so it is possible that they have addressed it. I haven’t had a chance to analyze the new code to verify that or not, just glanced at it. I should also note that despite the divide by zero error, the WIFI was working fine and I was able to get to the WebUI - just dead in the water due to the panic mode state. And $SS was useless as a troubleshooter, since technically there was no config problem at all.
Here is a link to a post that I mentioned which was experiencing a similar problem (just in case you think I’m crazy 
):
Edit: I should also note that during the troubleshooting process I reformatted the ESP and re-flashed it. This solved nothing.