fix: bounded retry with exponential backoff for 403 throttle responses

[jlima8900]

Summary

execute_rest() retries 403 throttled responses every 10 seconds with no maximum retry count. This causes Commander to hang indefinitely when throttled, and the fixed 10-second interval prevents the server's cooldown from expiring — creating a permanent throttle lock-in.

Changes

• Add max retry count (3 attempts) before raising KeeperApiError
• Parse the server's "try again in X minutes/seconds" message to determine wait time
• Use exponential backoff (30s, 60s, 120s) capped at the server's suggested cooldown
• Log throttle attempts as WARNING instead of DEBUG for visibility
• After max retries, raise KeeperApiError so callers can handle it programmatically

Behavior

Before	After
Retries every 10s forever	3 retries with exponential backoff, then error
DEBUG log only	WARNING log with attempt count
10s interval resets server's 1-min cooldown	Respects server's indicated wait time
No way for callers to handle throttle	Raises KeeperApiError after max retries

The --fail-on-throttle flag continues to work as before (immediate error, no retries).

Test plan

• Verify normal (non-throttled) requests are unaffected
• Verify throttled requests retry 3 times with increasing delay
• Verify KeeperApiError is raised after max retries
• Verify --fail-on-throttle still skips retries entirely
• Verify server's "try again in X" message is parsed correctly

[aaunario-keeper]

can we add a set of unit tests for this feature (verifying exactly what the test plan in your summary outlines?
For the execute_rest() throttle logic in rest_api.py, you'd test it with mocks in Python using unittest.mock:
The core idea: mock requests to return a fake 403 response, and mock time.sleep so tests don't actually wait.

[aaunario-keeper]

Also, can you squash your commits, this should only be 1 commit so it doesn't clutter up commit history