auth: add ClockSkew option to RequireBearerTokenOptions

[BorisTyshkevich]

Summary

• Add a `ClockSkew time.Duration` field to `RequireBearerTokenOptions` that bounds the tolerance applied to a token's `Expiration` when checking elapsed validity.
• Default zero preserves the existing strict comparison; positive values let resource servers tolerate the drift typical of distributed deployments and cloud-managed IdPs.

Motivation

Real-world resource servers running behind a CDN, in distributed deployments, or talking to an authorization server whose clock drifts a few seconds (common with cloud-managed IdPs) need a small positive tolerance when checking token expiration. Strict-equality comparison rejects tokens that are valid by the issuer's clock but momentarily appear expired by the verifier's. The reverse case — an issuer's clock running slightly fast at /token issuance — also reaches the verifier as a token whose `exp` lies microseconds in the past.

Test plan

• `go test ./auth/...` passes.
• New `TestRequireBearerToken_ClockSkew` exercises four cases: fresh accept, strict-expired reject, within-skew accept, beyond-skew reject.
• Existing `TestRequireBearerToken` continues to pass with `ClockSkew` defaulting to zero.

[guglielmo-san]

Suggested change

	skew := time.Duration(0)
	if opts != nil {
	skew = opts.ClockSkew
	}
	if tokenInfo.Expiration.Add(skew).Before(time.Now()) {
	if opts == nil {
	opts = &RequireBearerTokenOptions{}
	}
	if tokenInfo.Expiration.Add(opts.ClockSkew).Before(time.Now()) {