Honor per-operation retry policies in the generated client

[code-monger-givenall]

What changed

The generated Go client now follows each operation's x-hey-retry contract.

• It reads maxAttempts, baseDelayMs, backoff, and retryOn from generated operation metadata.
• WithMaxRetries and WithBaseDelay remain explicit overrides. Default client settings no longer replace operation defaults.
• UpdateClearance exports its natural idempotency into OpenAPI, so the generated PATCH method uses its retry policy.
• Raw WithBody methods buffer their input before retrying, so every attempt sends the complete body.

Why

Smithy says UpdateClearance gets two attempts and retries only 429 and 503. The generated client was not enforcing that contract. On current main, the new typed Screener operation also lost its idempotency marker during OpenAPI projection, which meant it did not retry at all.

Validation

• env GOWORK=off mise x -- make check
• 153 conformance cases passed
• Service tests cover the default attempt limit, retryable statuses, explicit overrides, and body replay

---

Summary by cubic

Honor per-operation retry policies in the generated Go client and mark UpdateClearance as naturally idempotent. This aligns client retries with the API contract and avoids unintended retries.

• Each operation now uses its x-hey-retry settings (maxAttempts, baseDelayMs, backoff, retryOn). The old global retryable statuses are gone; undeclared statuses (e.g., 500) no longer retry.
• generated.WithMaxRetries, generated.WithBaseDelay, and generated.WithRetryConfig override attempts and initial delay only. Retryable statuses always come from the operation’s policy.
• All raw *WithBody methods buffer the request body so each retry sends the complete body.
• UpdateClearance exports idempotency in Smithy/OpenAPI; the generated PATCH now follows its policy (2 attempts, retry on 429 and 503).
• Conformance runner no longer injects a global retry config; tests added to verify per-operation limits and allowed statuses.

Migration

• If you depended on the client retrying undeclared statuses (e.g., 500), add those statuses to the operation’s retryOn or stop relying on those retries. UpdateClearance will not retry 500.
• To change attempts or delay, pass generated.WithMaxRetries or generated.WithBaseDelay (or WithRetryConfig); these do not change which statuses retry.
• In the hey client, WithMaxRetries and WithBaseDelay apply only when set. Without overrides, per-operation defaults take effect.

^{Written for commit 148c20c. Summary will update on new commits.}