client: expose SDK retry policy controls

[goanpeca]

Summary

Expose the SDK retry configuration so workflows can tune retry count and backoff for large transfers, flaky networks, and rate-limited CI environments.

Why

The SDK automatically retries expired auth tokens, transient service errors, rate limits, and network failures. The action always uses SDK defaults, so teams cannot increase retry patience for large release artifacts or reduce retry time for latency-sensitive jobs.

SDK support (already available)

• B2ClientOptions.retry
• RetryOptions.maxRetries
• RetryOptions.initialRetryDelayMs
• RetryOptions.maxRetryDelayMs
• SDK retry handling for 401, 408, 429, 503, and network errors

Proposed surface

New optional inputs:

• retry-max-attempts or retry-max-retries
• retry-initial-delay-ms
• retry-max-delay-ms

These map to B2ClientOptions.retry during client construction. Omitting them preserves current defaults.

Acceptance criteria

• Retry inputs are parsed and validated as safe positive integers.
• The action forwards configured retry values to B2ClientOptions.retry.
• Defaults preserve current SDK behavior.
• Documentation explains when to increase or decrease retries.
• Tests verify the constructed client receives the expected retry configuration.

Out of scope

• Per-command retry overrides.
• Custom retry strategies beyond the SDK options.