Summary

Backport of #8501 to 1.x: Fix update cache invalidation across sbt command invocations when a dependency's dependencies change.

Problem

When project A's dependencies changed and A was compiled in one command, project B (depending on A) would not invalidate its update cache in a subsequent command. This caused stale classpaths.

The root cause was that depsUpdated only checked !stats.cached, which only detected fresh resolves within the same command. When a dependency was served from cache (even if resolved fresh in a previous command), cached was marked true by markAsCached, causing incorrect cache reuse.

Debug scenario from issue:
sbt:aaa> clean
sbt:aaa> a/compile
sbt:aaa> show itTests/depsUpdated
[info] * false <-- BUG: should be true

Solution

Instead of relying on the transient cached flag, we now hash the resolved module IDs (organization, name, revision) from each transitive dependency and include these hashes in the cache key (UpdateInputs).

• When any dependency's resolved versions change, the hash changes → cache is invalidated
• When dependencies stay the same, the hash stays the same → cache is reused correctly

Note: Unlike 2.x which adds a stamp field to UpdateStats in librarymanagement, this 1.x backport achieves the same goal without requiring changes to the external librarymanagement library.

Changes

• Change UpdateInputs type to include Vector[Long] for transitive dependency hashes
• Change depsUpdated: Boolean parameter to transitiveUpdates: Seq[UpdateReport]
• Remove !depsUpdated check from upToDate (now covered by input hash)
• Hash resolved module IDs from transitive updates for cache invalidation
• Add scripted test i8357-transitive-update-invalidation

Test plan

• Compiles successfully
• Run scripted test: scripted dependency-management/i8357-transitive-update-invalidation

Fixes #8357
Ref #8592