Rate limit RestateDeployment cleanup queries

[pcholakov]

Summary

Rate limit expensive RestateDeployment deployment-usage queries so resources targeting the same Restate Admin API endpoint do not multiply query load.

Approach and decisions

• Hold one endpoint-scoped query permit until the HTTP operation completes, covering both slow and failed queries.
• Defer event-driven reconciles while a query is running or the endpoint's minimum query-start spacing has not elapsed; do not sleep a controller task.
• Apply exponential retry delays for query-related failures: 30 seconds, 1 minute, 2 minutes, 4 minutes, then a jittered 5–6 minute ceiling.
• Key retry history by resource and expensive operation rather than the text of an error, and reset it only after the whole reconcile succeeds.
• Leave unrelated Kubernetes/finalizer/configuration failures on the existing controller behavior; they do not consume the query rate limit.
• Include a release note. The vqueues query rewrite remains deliberately deferred to Use vqueues for pinned RestateDeployment accounting when capability is proven #185: table presence does not prove persisted vqueues state is authoritative for every partition.

Validation

• RUSTC_WRAPPER='' cargo test --all-targets
• RUSTC_WRAPPER='' cargo clippy --all-targets -- -D warnings
• cargo fmt --check
• RUSTC_WRAPPER='' cargo test --lib controllers::restatedeployment::e2e -- --ignored --nocapture --test-threads=1

AI-generated investigation context

The rate limit is endpoint-scoped because one operator can manage RestateDeployment resources for multiple Restate environments. The permit stays in flight until the HTTP request completes, preventing a second resource from starting an expensive query after a fixed delay while a slow first query is still running. Retry scheduling uses deferred reconciles and jitter to avoid synchronized retry bursts.

[lukebond]

let's see if #190 is enough before we go down this route. as i note in the description of that PR, there are still scenarios where the query may run a lot, and in those cases this (and Ben's addition) seem appropriate. but let's not unless we need it.