Delaying newly changed dependencies

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Feature description

I would like the ability to only consider bundler gems that have not had a release for 6 days. The mindset here is to avoid being on the bleeding edge, and avoid potentially bad releases.

I cite the [draper gem](https://rubygems.org/gems/draper) as an example. It had the following recent releases:

- [4.0.4](https://rubygems.org/gems/draper/versions/4.0.4) January 28, 2025 (69.5 KB)
- [4.0.5](https://rubygems.org/gems/draper/versions/4.0.5) November 12, 2025 (32 KB)
- [4.0.6](https://rubygems.org/gems/draper/versions/4.0.6) November 16, 2025 (32 KB)

Release 4.0.5 introduced an unannounced breaking change. Release 4.0.6 reverted that change.

I originally thought that "cooldown 6" would meet my needs here, but unfortunately it just delays a dependency until it is 6 days old (in my case).

So on November the 19th dependabot with "cooldown 6" would offer me draper 4.0.5 even though 4.0.6 was released on the 16th which contains the fix. So in my case "cooldown 6" would just delay me being on the bleeding edge, it would not avoid it.

The functionality I would like is to not update any gem that has had any release in the specified period. So "no releases for 6 days" would act as follows:

- On the 13th November it would not offer v4.0.4 since it was released the day before
- On the 19th November it would not offer v4.0.4 or v4.0.5 since v4.0.5 was released 3 days before.
- On the 23rd November it would offer me v4.0.6 since there has not been a new version released for 6 days.

Obviously there are corner cases here, for instance if a gem were always releasing a new version every 3 days then in my case I would never be offered an update. Personally I've not ever encountered a gem that releases in that manner, and if it were a concern I would have to use a different approach. I could for instance set the limit to 2 days. Unfortunately if this functionality behaved like "cooldown" then I couldn't use groups since "cooldown" can only be specified at the ecosystem level, not at the group level (which would be nice in this case).

Another potential corner case might surround semantic versioning and dependency constraints. E.g. suppose I specified that my application only supports < v7. If a release to v6 came out and then a few days later a release to v7, then one could argue that the v7 release doesn't need to affect the decision on the v6 patch. However that supposes that the versions are semantic, ultimately I'd be happy with the simple logic that any release, regardless of version, counts and thus resets the timer.

No file or test is named. Start by tracing the Bundler cooldown and group-configuration paths, then examine how dependency release dates are available to update selection. Done means an option can withhold a gem while any version has been released within the configured period, including the documented Draper scenarios.

Written by the indexing model from the issue text.