Very slow `EverInitializedPlaces` analysis on async fn with many awaits

I have a tool that generates code and for debugging purposes that has a function that summarizes the state of the whole thing. So that's an async function with potentially a lot of awaits.

I posted in this issue first: https://github.com/rust-lang/rust/issues/138828#issuecomment-3132174620
But then was advised to open a new issue. And after that I was able to reduce it much further.

I tried this code:
https://gist.github.com/diondokter/ec4659f8b80b3f92643138606df5fa93#file-repro-rs
(Very long so in a gist)
rustc +nightly compile_time_explosion.rs --edition 2024 -Ztime-passes

I expected to see this happen: relatively normal compile times

What happens instead is that this takes 21 seconds.

...
time:   0.000; rss:   33MB ->   32MB (   -1MB)  drop_ast
time:   0.000; rss:   32MB ->   32MB (   +0MB)  looking_for_entry_point
time:   0.000; rss:   32MB ->   32MB (   +0MB)  looking_for_derive_registrar
time:   0.000; rss:   33MB ->   33MB (   +0MB)  unused_lib_feature_checking
time:   0.003; rss:   32MB ->   33MB (   +1MB)  misc_checking_1
time:  21.327; rss:   33MB ->   93MB (  +60MB)  coherence_checking
time:   0.000; rss:   93MB ->   93MB (   +0MB)  emit_ast_lowering_delayed_lints
time:  21.328; rss:   33MB ->   93MB (  +60MB)  type_check_crate
time:   0.506; rss:   93MB ->  100MB (   +7MB)  MIR_borrow_checking
time:   0.000; rss:  100MB ->  100MB (   +0MB)  layout_testing
time:   0.000; rss:  100MB ->  100MB (   +0MB)  abi_testing
time:   0.000; rss:  100MB ->  100MB (   +0MB)  crate_lints
time:   0.003; rss:  100MB ->  101MB (   +0MB)  module_lints
...

The coherence checking also seems to be quadratic or something.
This is the compile time changes in my tool:

Start with the reduced repro in the linked compile_time_explosion.rs gist and run rustc +nightly compile_time_explosion.rs --edition 2024 -Ztime-passes. Compare the reported scaling as the number of awaits increases, focusing first on the coherence_checking and type_check_crate phases. Done means identifying and addressing the cause of the excessive compile time and confirming improved scaling on the repro.