I found the main issue: It was STP. there was an exact 30 second delay before dhcp completed, just enough for the rest of the system to start up, which in turn caused the apps service to get confused.
Adding a PRE Init command with ip link set br0 type bridge stp_state 0 restores the previous behaviour.
The broader issue here appears to be the Apps service specifically being pretty fragile. There was a prior issue with a fixed timeout that was too short and required manually (re)starting the apps service if it didn’t initialize at first.
This seems like a similar category where it doesn’t fully wait for the network to be up, tries to start, fails and just never does anything again. I was able to “fix” the Apps service on a “broken” system by unsetting and setting the pool again, which (re)started the apps service and everything worked fine.
But for now getting rid of the STP delay also works. In the long term maybe a more robust restart/retry logic for the apps service might be worth a consideration…