Webhook with a timeoutSeconds greater than 29 seconds will block upgrades?

I'm trying to upgrade from dok8s v1.28 to v1.29, but clusterlint is telling me that cert-manager's webhook, which uses a `timeoutSeconds` of 30, will block the upgrade. Would someone mind filling me in on why that's the case suddenly? I've been using cert-manager for years, across several k8s versions, without issue. I see in [the upstream docs](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#timeouts) where it says:

> The timeout value must be between 1 and 30 seconds.

But it's unclear whether that's inclusive or not. Clusterlint has seemingly decided that it's 1-inclusive and 30-exclusive. Is that actually based in reality? Is there another document I've missed? 29 seems so random, haha!

For now I will customize my deployment and set this to 29 to make clusterlint happy, but I'd like to get to the bottom of this. I've [logged an issue against cert-manager as well](https://github.com/cert-manager/cert-manager/issues/6907). If clusterlint is correct, cert-manager should probably make the default value 29. On the other hand, if 30 is indeed a valid value, clusterlint probably shouldn't complain about it.

Start by reproducing the clusterlint upgrade check for cert-manager's webhook with timeoutSeconds set to 30, then trace the clusterlint rule that reports the violation. Compare its behavior with the Kubernetes admission webhook timeout documentation and the linked cert-manager issue. Done means establishing whether 30 seconds is valid and documenting or correcting the resulting clusterlint behavior.

Written by the indexing model from the issue text.