fix(client): retry rate limits and reduce polling

[rm-you]

A single HTTP 429 during server creation, deletion, or status polling currently fails the operation. The one-second status polling interval also adds substantial API load when multiple runners are provisioning.

Configure each service client's Gophercloud retry hook for up to 10 retries on rate-limit responses (429 and Gophercloud's existing 498 handling). Honor Retry-After seconds or HTTP dates; otherwise use exponential backoff from 2 seconds with jitter, capped at 60 seconds. Backoff respects context cancellation. Poll server status every five seconds after the previous check completes, retaining the existing operation deadlines.

Tests cover client configuration, create/delete recovery, the 11-request limit, non-rate-limit errors, Retry-After parsing and overflow, cancellation, and polling cadence. Timer tests use Go's virtual clock without changing production intervals. Full vendored tests with the race detector, repository lint, formatting, and dependency consistency checks pass.

The retry policy applies after service-client initialization. Initial authentication, endpoint discovery during construction, and Keystone reauthentication are outside this change; the existing constructor authenticates before exposing the ProviderClient.