Ah, I see a possible issue. Datasheet says IO2 needs to be low to enter the proper download mode, you pull it high (R7 R9). Try not doing that and see if that helps.

Are you sure you're not using an ESP32 (module) with PSRAM? If so, GPIO 17 is generally unavailable.

Sorry, I'm not seeing anything odd in your schematic or in what you tell me that could have caused this behaviour, and I can't say I ever ran into this before.

Can you put the bypass caps closer to the ESP32, i.e. solder them to the PCB rather than use wires? Those wires can pick up noise from the environment and inject it into Vdd_sio. Additionally, they'll have a non-negligable inductance, likely negating the purpose of that decoupling cap.

Did you call gpio_install_isr_service() anywhere?

Physically, it's possible. But I don't think there's any existing drivers or other infrastructure for this yet, so you'd have to build that from scratch.

Possibly a cleaner way (that might also work with ULP, I don't know) is to make those shared things into its own header-only component, then use EXTRA_COMPONENT_DIRS in the projects to point to that an REQUIRES in the components that need it?

+1 on what MicroController said; doing something expensive and dangerous like creating a task from an ISR is unlikely to ever be a good idea.

Hard to say. Tx uses a fair bit of power, but Rx also is not cheap ( datasheet section 5.5 indicates about 100mA) but by the time DHCP is active, presumably DTIM would already have kicked in (depends on the access point and your configuration) lowering that number by a fair bit. Do you have any idea...

Odd. Do you see this behavior on multiple PCBs or only one?