Avoid post-construction mutation of provider cooldown settings

[LalatenduMohanty]

Problem

Cooldown settings are applied to providers by mutating them after construction:

provider = get_prebuilt_wheel_provider(...)
provider.cooldown = resolver.resolve_package_cooldown(ctx, req)
provider.supports_upload_time = False

This happens in three places (resolver.py, sources.py, wheels.py). The pattern was chosen so that plugin authors don't need to handle cooldown in their get_resolver_provider overrides — the framework applies it after the fact.

It works, but it's fragile:

• Providers exist in a partially-configured state between construction and mutation
• Forgetting to set cooldown at a call site silently disables it
• Nothing enforces that the mutation happens

Flagged by @tiran in PR #1018 review.

Possible approaches

Approach	Tradeoff
Wrap the provider after find_and_invoke() in a factory that applies cooldown automatically	Adds indirection but removes caller responsibility
Add a post-invoke hook to find_and_invoke() that configures the returned provider	Centralizes the logic but changes the find_and_invoke contract
Pass cooldown through find_and_invoke() kwargs to the constructor	Simple but requires plugin authors to accept and forward it
Keep the current pattern and document it	No code change; risk stays

Whichever approach we pick should preserve the property that plugin authors do not need to know about cooldown when implementing get_resolver_provider.

References

• PR feat(resolver): add release-age cooldown to protect against supply-chain attacks #1018: feat(resolver): add release-age cooldown to protect against supply-chain attacks #1018
• Original feature issue: add cooldown period when resolving version numbers during bootstrapping #877