Feat: Polly support

[HavenDV]

What would you like to be added:

Why is this needed:

Anything else we need to know?

[HavenDV]

As of April 6, 2026, the competitor baseline here is broader than "Polly support" alone.

Relevant references:

• Fern retries: https://buildwithfern.com/learn/sdks/deep-dives/retries-with-backoff
• Fern SDK user features: https://buildwithfern.com/learn/sdks/deep-dives/sdk-user-features
• Speakeasy retries: https://www.speakeasy.com/docs/sdks/customize/runtime/retries
• Speakeasy SDK hooks: https://www.speakeasy.com/docs/sdks/customize/code/sdk-hooks
• Stainless client settings: https://www.stainless.com/docs/sdks/configure/client

What competitors already cover:

• Fern: exponential backoff, retryable status codes (408/429/5xx by default), client-level override, request-level override.
• Speakeasy: global and per-request retry config via x-speakeasy-retries; runtime override via generated retry config objects; retries reuse the original idempotency key when one exists.
• Stainless: retries with exponential backoff, Retry-After / Retry-After-Ms, X-Should-Retry, configurable timeouts, and idempotency-key support.

Suggested scope for this issue:

• First-class generated retry abstraction for C# SDKs rather than only "wire in Polly manually"
• Sensible defaults for network errors, 408, 429, and 5xx
• Client-level override and per-request override
• Respect Retry-After and similar retry headers
• Integrate cleanly with idempotency semantics for non-GET retries
• Optional Polly adapter/integration can still be part of the implementation story, but the SDK-facing feature should not depend on users hand-assembling policies

In other words: this issue probably wants to cover generated resilience behavior first, and Polly support second.