Rate-limit the /v1/rotate endpoint

[0xVijay]

What this does

Wraps the /v1/rotate handler in the same httpRateLimiter.RateLimit(...) chain that /v1/verify already uses, and clarifies the help text on --rate-limit / --rate-limit-burst to reflect that both endpoints are covered.

Why

/v1/rotate decrypts a SealedSecret with the controller's private key and re-encrypts it with the latest sealing key — a full RSA-OAEP decrypt + re-encrypt on every request. The default Helm chart binds system:authenticated to the proxier role, so any user with a valid cluster credential can reach the endpoint via the kube-apiserver proxy and flood it. The CPU goes to 100% and SealedSecret reconciliation stalls across the whole cluster.

/v1/verify was already rate-limited at pkg/controller/server.go:49. Rotate just needs the same wrapper.

This was discussed in advisory GHSA-jpp5-6cf2-prqh — @alvneiayu accepted it as a genuine improvement and suggested opening a regular issue / PR. Sending the PR directly.

Change

-	mux.Handle("/v1/rotate", Instrument("/v1/rotate", http.HandlerFunc(func(...) {
+	mux.Handle("/v1/rotate", Instrument("/v1/rotate", httpRateLimiter.RateLimit(http.HandlerFunc(func(...) {

Plus a one-word help-text update on the two existing rate-limit flags so the docs match the behaviour.

Notes

• No new flags introduced — reuses the existing --rate-limit / --rate-limit-burst quotas so deployments don't need configuration changes.
• Behaviour parity with verify means 429 Too Many Requests once the per-source GCRA bucket is exhausted.
• Happy to add a test that exercises the limiter on rotate if you want one. I noticed there's no equivalent test for verify today so I kept the change minimal — let me know.

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions]

Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.