Bridging the gap between cabal's rebuild logic and end-users

A question I often ask myself after having switched to another branch at work is "Why do my dependencies need to be rebuilt?".

As an end-user I have the following output:

```
Configuration is affected by the following files:
- cabal.project
- cabal.project.freeze
- cabal.project.local
Build profile: -w ghc-9.6.6 -O1
In order, the following will be built (use -v for more details):
- barbies-2.1.1.0 (lib) (requires build)
- comonad-5.0.8 (lib) (requires build)
- data-default-0.7.1.1 (lib:data-default) (requires build)
[…]
- my-project-1.0 (lib) --enable-profiling (configuration changed)
```

And now I have to rebuild all of the 333 dependencies (direct & transitive) of the project.

My `cabal.project.local` file looks like this:

```
ignore-project: False
with-compiler: ghc-9.6
profiling: True
profiling-detail: all-functions
```

And (I must stress this) **always remains the same between branches**.

Is cabal unable to preserve the cache of a build with profiling? Can I somehow make it spill the beans as to why a cache has to be invalidated? This would be a great improvement for projects that have a consequent amount of total dependencies.

Reproduce the branch-switch rebuild using cabal.project, cabal.project.freeze, cabal.project.local, GHC 9.6, and profiling enabled. Start from Cabal's reported configuration changes and build plan; done means explaining why unchanged profiling builds invalidate dependencies and identifying a concrete way to preserve or expose the cache decision.

Written by the indexing model from the issue text.