fix(cli): align cache warm hashes with generation

What changed

Backports #11616 to releases/4.201.x.

This cherry-picks the landed main commit 8dc1e153f18b8d08b642a1ee79e12eaaa2771f14, which:

• keeps the cache-warm preload graph normalized with FrameworkSearchPathsGraphMapper
• preserves the same normalized hashing graph before TargetsToCacheBinariesGraphMapper runs in generate/build flows that were not already preserving it
• adds unit coverage for mapper ordering
• adds acceptance coverage that warms a framework wrapping precompiled dependencies, then verifies generate --cache-profile all-possible reuses and links the warmed binary

Why

The RC can otherwise store a warmed target under a different cache key than the one requested by tuist generate --cache-profile all-possible.

The regression was introduced by #11054 (de9b946c217), which moved generated framework search paths into FrameworkSearchPathsGraphMapper. Cache warm included those generated settings in the target-settings hash, while unfocused generate/build cache replacement could request binaries using a hash computed before the same normalized graph had been preserved.

Approach

This is a direct cherry-pick from main; no manual code changes were made during the backport.

The fix keeps cache warm behavior intact and instead makes generate/build preserve the same normalized hashing graph before binary replacement. That avoids reintroducing the default/focused cache reuse regression while aligning warm and consume cache keys.

Validation

• The original PR was validated locally and passed CI on main.
• For this backport, I only verified that the cherry-pick applied cleanly and contains the expected files/commit. No additional local checks were run.