fix(verify): add upper bound of 300 seconds for clockTolerance option

[Pranav18M]

Fixes #1021

Adds an upper bound of 300 seconds to the clockTolerance option in
verify().

The existing PR #1036 correctly rejects invalid values (NaN, Infinity,
negative) but does not cap the maximum value. A large-but-finite
clockTolerance like Number.MAX_SAFE_INTEGER still effectively bypasses
expiry verification since exp + 9007199254740991 produces a value far
larger than any realistic clockTimestamp, causing expired tokens to be
silently accepted.

Any clockTolerance above 300 seconds is almost certainly a
misconfiguration and poses a security risk.

Description

Adds an upper bound validation for the clockTolerance option in
verify(). When clockTolerance exceeds 300 seconds, a
JsonWebTokenError is thrown immediately, preventing accidental or
malicious expiry bypass via large tolerance values.

References

• Fixes Bug: clockTolerance accepts arbitrarily large values, bypassing exp verification entirely #1021
• Related PR: fix(verify): validate clockTolerance is a non-negative number #1036 (handles NaN/Infinity/negative but not upper bound)

Testing

The fix can be tested by calling jwt.verify() with clockTolerance
set to a value greater than 300 (e.g. 301 or Number.MAX_SAFE_INTEGER)
and confirming a JsonWebTokenError is thrown with the message
"clockTolerance must not exceed 300 seconds to prevent accidental
expiry bypass".

Environment: Node.js v20, jsonwebtoken v9.0.3

• This change adds test coverage for new/changed/fixed functionality
• All active GitHub checks for tests, formatting, and security are passing