Cooldown check blocks transitive dependency that matches top-level exact pin

[LalatenduMohanty]

When a package appears both as a top-level exact-pinned requirement (foo==1.0) and as a transitive dependency of another top-level requirement (bar depends on foo>=0.9), the cooldown check can block or downgrade the transitive resolution even though the user explicitly approved that version.

Steps to reproduce

1. Requirements file with multiple top-level pins:

   foo==1.0
   bar==2.0
   

2. bar depends on foo>=0.9
3. foo 1.0 was published within the cooldown window (e.g., 2 days ago, cooldown is 7 days)
4. Run bootstrap with --min-release-age 7

What happens

• foo==1.0 resolves successfully (top-level exact pin bypasses cooldown)
• bar==2.0 resolves successfully
• When bar's transitive dependency foo>=0.9 is resolved, it goes through a separate resolution path with req_type=INSTALL. Cooldown is enforced, blocking version 1.0
• Result: either an older version is selected (contradicting the pin) or resolution fails

Root cause

resolve_package_cooldown() in resolver.py only bypasses cooldown for req_type == TOP_LEVEL with an exact == pin. The transitive resolution uses a different requirement string (foo>=0.9 vs foo==1.0), so the session cache is also a miss. The resolver has no way to know that this package+version was already approved as a top-level pin.

Expected behavior

If a package already has a top-level exact-pinned entry in the dependency graph, cooldown should be bypassed when the same package is resolved as a transitive dependency.

Suggested fix

In resolve_package_cooldown(), check the dependency graph for an existing top-level exact-pinned entry for the package. If one exists, return None (bypass cooldown) for transitive resolution of the same package.

[LalatenduMohanty]

Issue with PR #1154 fix

The fix in #1154 bypasses cooldown entirely (return None) for transitive deps when a top-level == pin exists. This is too broad — it disables cooldown for all versions of the package, not just the pinned version.

Example: If foo==1.0.0 is pinned top-level and a transitive dep requires foo>=1.0.0, the cooldown bypass allows foo==2.0.0 (within the cooldown window) to be selected instead of the pinned 1.0.0.

Expected: Only the pinned version (1.0.0) should bypass cooldown. Other versions should still be subject to the cooldown window.

Fix in progress: Reverting #1154 and replacing it with a version-specific exemption — adding an exempt_versions field to the Cooldown dataclass so that only the graph's pinned version(s) bypass cooldown, while all other versions remain subject to the cooldown filter. This is similar to how repeatable build mode falls back to versions already in the dependency graph.