I looked around the EC firmware a bit (which is open-source), and I’m pretty sure this “firmware connection manager” does not run in there. I suspect there is just an actual MCU or so inside the Tiger Lake CPU inside the TB controllers that handles this. Also, the kernel sources suggest that (unlike earlier xxx ridge external TB chips) tiger lake does not have updateable NVM for firmware, so maybe this firmware is hardcoded in ROM inside the CPU (or maybe flashed as part of microcode, BIOS, or some other non-TB-specific firmware?).
I did find some code inside the EC that handles the power-on-AC-attach, so the EC is at least capable of turning the system on (obviously, since it also handles the power button). However, it seems not all powering on runs through the EC, since I also noticed that when no AC power is present, the EC really powers itself down by cutting off its own power supply, rather than neatly going into deep sleep with some interrupt wake up sources left on suggested in this comment. It does use the internal VCI module to allow powering itself back on when a button press happens (using two GPIO lines from the “power button” on the mainboard, or the “fp” fingerprint-powerbutton), but this does not seem to handle power on on AC-attach - so there must be some external circuitry that handles powering on at least the EC on EC attach (and maybe also the entire system and handle the power-on-AC setting, since I could not find any evidence in the EC firmware source that it actually triggers the HOOK_AC_CHANGE on startup, so if plugging in power would only start the EC, it would never seem to power on the system - but I’m probably missing something here).
In any case, I wondered if it is also the EC that turns the system on in the problematic case. Probably not, but I had hoped to confirm this. I did find the ectool console command (with the customized-for-framework ectool version from Exploring the Embedded Controller), but the EC produces too much output during boot, so I cannot see the output from the actual power-up moment, unfortunately…
I’ve also tried looking for wakeup sources in the thunderbolt kernel module, but not much luck. I did find two possibly relevant wakeup sources in powertop: My keyboard, and the ethernet adapter. Disabling these and then hibernating prevented wakeup using the keyboard, as expected, but did not prevent wakeup when unplugging the dock, so that’s not it… (the wakeup-on-keyboard thing did make me wonder how much logic and power supplies are left running when you hibernate - it seems like the system isn’t fully off, but the CPU is still in some sleep state with the USB controller still running or sleeping, so I’m curious how much power is still used. Not much of a problem in this particular case, since there will be wall power if there is a keyboard, but still. And of course, when disconnecting wall power, such extra drain should maybe be removed, so maybe that’s why this wakeup-on-disconnect is implemented by the firmware?).