Fix rate limit sleep duration calculation

[Krishnachaitanyakc]

Summary

Fixes #1121

The rate limit handler in BaseLLMClient.__call__ used wait_time.seconds to compute the sleep duration, which is incorrect for timedelta objects that span multiple days. Python's timedelta.seconds only returns the seconds component within the current day (0-86399), not the total number of seconds:

• timedelta(days=1) (daily rate limit reset) has .seconds = 0, causing a zero-second sleep that immediately retries and gets rate-limited again in a busy loop
• A negative timedelta from clock drift (e.g. timedelta(seconds=-5) = timedelta(days=-1, seconds=86395)) has .seconds = 86395, causing a ~24-hour sleep

Changes

• core/llm/base.py: Replace wait_time.seconds with int(wait_time.total_seconds()) and clamp the result to a 1-3600 second range. This prevents both zero-second busy loops and excessively long waits (over 1 hour) that make the tool unusable. Also adds log.info() so rate limit sleeps are always logged.
• tests/llm/test_rate_limit.py: Add 8 new test cases covering normal durations, large values (capped at 3600s), daily rate limits, negative timedeltas, fractional seconds, and the case where rate_limit_sleep returns None.

Test plan

• All 101 existing + new tests pass (python3 -m pytest tests/llm/ -v)
• Verify with an actual rate-limited API key that the sleep duration is correct and within bounds
• Confirm that insufficient-funds RateLimitError (where rate_limit_sleep returns None) still raises APIError without sleeping

[CLAassistant]

All committers have signed the CLA.