Consider clock skew for Identity security stamp validation intervals

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Is your feature request related to a problem? Please describe the problem.

`SecurityStampValidator` currently validates when the current time minus the cookie's `IssuedUtc` is greater than `SecurityStampValidatorOptions.ValidationInterval`.

A separate machine may trigger reauthentication on a regular cadence close to that boundary. Examples include a browser scheduling SignalR authentication refresh or a request being handled by a different server than the one that issued the cookie. Timer rounding, request latency, and clock differences can cause the request to arrive slightly before the validation interval. The security-stamp check is then skipped until the next scheduled reauthentication cycle, potentially delaying revocation substantially.

### Describe the solution you'd like

Investigate whether Identity security-stamp validation should allow a small early-validation window, similar to clock-skew handling elsewhere. Conceptually, a request arriving shortly before `ValidationInterval` would be allowed to perform the stamp check instead of waiting for another full cycle.

For example:

```csharp
var validationThreshold = Options.ValidationInterval - validationClockSkew;
validate = timeElapsed >= validationThreshold;
```

The design should consider whether the skew is an internal framework policy or configurable, how it behaves when `ValidationInterval` is shorter than the skew, and the impact of slightly more frequent database checks.

### Additional context

This came up while integrating Blazor Identity with SignalR authentication refresh in #68663 on top of #68676. The current prototype uses a 40-minute maximum authentication expiration so SignalR's five-minute refresh lead causes reauthentication around minute 35, safely after Identity's default 30-minute validation interval. An Identity-level early-validation window could make boundary-based integrations less sensitive to timer and clock differences.

Start with SecurityStampValidator and SecurityStampValidatorOptions, focusing on the IssuedUtc and ValidationInterval comparison described in the issue. Review the SignalR authentication-refresh context in #68663 and the prototype in #68676. Done means an agreed policy for early validation, configurability, short intervals, and the impact on database checks.

Written by the indexing model from the issue text.