Configuration cache is unusable in large projects when running `./gradlew projectHealth`

**Build scan link**
Internal scan unfortunately

**Plugin version**
Latest master (1.28.0)

**Gradle version**
8.6

**JDK version**
17

**Describe the bug**
When trying to integrate the latest version of the dependency analysis plugin into our codebase, we observed super slow configuration phases with Gradle. I ran `./gradlew projectHealth` on my laptop and this is the result:

```
du -sh .gradle/configuration-cache/*
4.1G .gradle/configuration-cache/3xf2m0hsy44d2s1o8ckwbboiy
```

Before, the largest configuration cache side I had on my machine was 24MB. Gradle spent about 2 minutes in the "Storing configuration cache state" and then proceeded to run for 20 minutes in "Loading configuration cache state" after which I killed the process as I didn't expect it to finish.

Unfortunately the caches themselves are `.bin` files, so I can't give you anymore information of which particular part of the cache is large. I also suspect the size of the configuration cache correlates with the number of Java files, as we configure them in file collections.

**To Reproduce**
Steps to reproduce the behavior:
1. Have a lot of code in a lot of modules
2. Enable Gradle configuration cache
3. Run `./gradlew projectHealth`

**Expected behavior**
The configuration cache for a run that includes `projectHealth` is within reasonable bounds compared to other tasks. In our case, we expect the cache to be smaller than 30 MB. It also should not cause the configuration cache storing and loading to take minutes for large builds. For a smaller build of ours, it still took 6 seconds to load the full configuration cache, where the entry is 211MB (about 1/4th of all modules included in this build, but typically excludes the largest ones we have).

CC @cobexer and @ljacomet who contributed the configuration cache fixes in #1039

The issue names the ./gradlew projectHealth entry point, Gradle configuration cache, and prior configuration-cache fixes in #1039, but no source files or tests. Start by reproducing projectHealth with configuration caching in a large multi-module build and measuring cache size and load/store times. Done means the cache stays within the reported reasonable bounds and no longer takes minutes to load or store.

Written by the indexing model from the issue text.