KeyRingProvider uses 24h refresh period even with expired keys and disabled key auto-generation

[DunetsNM]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When KeyRingProvider uses an expired key with AutoGenerateKeys = false, it schedules the next refresh for up to 24 hours in the future:

aspnetcore/src/DataProtection/DataProtection/src/KeyManagement/KeyRingProvider.cs

Lines 187 to 198 in 0230498

	var nextAutoRefreshTime = now + GetRefreshPeriodWithJitter(KeyManagementOptions.KeyRingRefreshPeriod);
	// The cached keyring should expire at the earliest of (default key expiration, next auto-refresh time).
	// Since the refresh period and safety window are not user-settable, we can guarantee that there's at
	// least one auto-refresh between the start of the safety window and the key's expiration date.
	// This gives us an opportunity to update the key ring before expiration, and it prevents multiple
	// servers in a cluster from trying to update the key ring simultaneously. Special case: if the default
	// key's expiration date is in the past, then we know we're using a fallback key and should disregard
	// its expiration date in favor of the next auto-refresh time.
	return new CacheableKeyRing(
	expirationToken: cacheExpirationToken,
	expirationTime: (defaultKey.ExpirationDate <= now) ? nextAutoRefreshTime : Min(defaultKey.ExpirationDate, nextAutoRefreshTime),

This creates a problem in multi-application scenarios where:

1. App A generates keys
2. App B has AutoGenerateKeys = false and relies on App A for new keys, but starts few minutes earlier than App A
3. When App B's key expires, it waits up to 24h before checking for new keys from App A

Since App B explicitly disabled auto-generation, it depends on other apps for new keys and should check for them more frequently when using expired keys (e.g., every 5 minutes).

Suggested fix:
Use a shorter refresh period when defaultKey.ExpirationDate <= now && !_keyManagementOptions.AutoGenerateKeys