In Guix, how to figure out which package in a manifest adds a specific dependency to the profile?

I've made my Guix system entirely declarative, always adding packages through guix package -m mymanifest.scm. Sometimes this fails because of conflicting dependencies. E.g. right now I have gcc-toolchain in my manifest, amongst dozens of other packages, and this message shows up:

guix package: error: profile contains conflicting entries for gcc-toolchain
guix package: error:   first entry: gcc-toolchain@12.3.0 /gnu/store/rfm800pq3q2midj29a4xlikdzjp1ps2l-gcc-toolchain-12.3.0
guix package: error:   second entry: gcc-toolchain@11.3.0 /gnu/store/ks87cpc36kh8hqwr569pks4yrzfl7mnv-gcc-toolchain-11.3.0
hint: You cannot have two different versions or variants of `gcc-toolchain' in the same profile.

I suppose gcc-toolchain that is included in the manifest is 12.3.0, and some other package has gcc-toolchain@11.3.0 as an (indirect) dependency. But I don't know which package that is. In this particular case, the problem was easily resolved, because I also included gcc in the manifest, and that resulted in the warning that package 'gcc' has been superseded by 'gcc-toolchain', and removing gcc seems to have fixed the issue. However, I'd like a more general applicable method to find the 'offending' package. That is, given a manifest file, say mymanifest.scm, how can I figure out through which dependency chain a given package, say gcc-toolchain@11.3.0, ends up in the profile? I usually do a binary search, by simply commenting out (or back in) half of the packages and see when the problem disappears (or reappears), but this is a manual and tedious process. The ugly naive way I can automate this myself would be to loop through all the packages, call guix graph on each package, and then grep for the problematic dependency. Better would be to figure out what guix graph is doing, and do that for a whole manifest. Or perhaps convert a manifest into a package (empty, except for dependencies), and then call guix graph on that. But there is probably a better way.