File include analysis:

• dictionary.cpp 93 -> 93 (+0)
• type_info.h 4 -> 70 (+66)
• variant_call.cpp 94 -> 93 (-1)
• variant_construct.cpp 94 -> 76 (-18)
• variant_destruct.cpp 82 -> 72 (-10)
• variant.cpp 106 -> 102 (-4)
• variant_op.cpp 83 -> 75 (-8)
• variant_parser.cpp 110 -> 110 (+0)
• variant_setget.cpp 90 -> 90 (+0)
• variant_utility.cpp 106 -> 97 (-9)
  Total: -50 (excluding type_info.h), +16 (including type_info.h)

class_db.h was included in all files excluding type_info.h.
It is no longer included in variant_construct.cpp, variant_destruct.cpp, variant_op.cpp (-3 includes).
Still remains in:

• dictionary.cpp through container_type_validate.h ... through resource.h and refcounted.h
• variant_call.cpp through marshalls.h ... through refcounted.h
• variant_op.cpp through resource.h
• variant_parser.cpp through resource.h and refcounted.h
• variant_setget.cpp through resource.h and refcounted.h
• variant_utility.cpp through resource.h and refcounted.h

#111567 is the first step towards finishing the delineation from class_db.h for the entirety of core/variant
#111573 is the second step

Looks like there will always be an issue with container_type_validate.h though, which also means dictionary.cpp

I agree that these changes will likely have minimal (if any) performance benefits. The justification of "delineating from class_db.h" may thus be considered misguided.
However, I would say these changes are still worth doing, since they clean up the headers for the variant_ files, which are currently bloated. They were bloated due to type_info.h not having its required include, but since that gets fixed by this PR, I would argue that bundling together the bloat removal is the correct thing to do.

Let me know if you would like me to split the PR into one that focuses solely on type_info.h and a second (if even) that focuses on the subsequential clean-up.

I agree that these changes will likely have minimal (if any) performance benefits. The justification of "delineating from class_db.h" may thus be considered misguided. However, I would say these changes are still worth doing, since they clean up the headers for the variant_ files, which are currently bloated. They were bloated due to type_info.h not having its required include, but since that gets fixed by this PR, I would argue that bundling together the bloat removal is the correct thing to do.

Let me know if you would like me to split the PR into one that focuses solely on type_info.h and a second (if even) that focuses on the subsequential clean-up.

I think we should merge the type_info.h changes, to avoid potential future build problems.
But the other changes to variant_ files are not as relevant. I agree the includes are a bit messy, but every change we make to the codebase has some risk to cause regressions (e.g. break builds for modules), so we should have a good reason to merge the change. Since the variant_ changes won't have an effect on build time, and won't bring us closer to isolating ClassDB, I don't think they qualify.

Changes to type_info.h have been isolated and are now the only thing included in the PR.
Updated PR title and description to reflect the change.

So do I... Hopefully the daily runner proposal gets approved and that gets included in there.
I might try and run a similar check as you proposed on my machine and start opening PRs for any issues that I find. I expect new files to not have this issue (maybe extremely rarely they might), so that work should be "enough" for now.

Thanks!