fix: correct rate limiting calculation to prevent incorrect delay display

[roomote]

Description

This PR fixes an issue where users were seeing an incorrect rate limiting message displaying "Rate limiting for 15903 seconds..." when using the DeepSeek API provider.

Problem

The rate limiting calculation in Task.ts was not properly handling cases where:

1. Task.lastGlobalApiRequestTime was undefined (on first request)
2. rateLimitSeconds was 0 or undefined

This resulted in incorrect delay calculations that showed unrealistic wait times.

Solution

• Added check for rateLimit > 0 before applying rate limiting logic
• Moved the rate limit configuration check outside the timestamp conditional
• Only calculate and apply delay when there's actually time remaining to wait
• Simplified the calculation to be more explicit about when delays should be applied

Testing

• ✅ All existing tests pass
• ✅ Linting passes
• ✅ Type checking passes
• ✅ Manual testing confirms the issue is resolved

Related Issue

Fixes #7770

Changes Made

• Modified rate limiting calculation in src/core/task/Task.ts (lines 2527-2540)

Impact

This fix ensures that rate limiting messages are only displayed when:

1. A valid rate limit is configured (> 0 seconds)
2. There's actually time remaining to wait based on the last request timestamp

Users will no longer see incorrect rate limiting messages when using DeepSeek or other providers without rate limiting configured.

---

Important

Fixes rate limiting calculation in Task.ts to prevent incorrect delay messages by ensuring valid rate limits and adjusting delay logic.

• Behavior:
  • Fixes rate limiting calculation in Task.ts to prevent incorrect delay messages.
  • Adds check for rateLimit > 0 before applying rate limiting logic.
  • Moves rate limit configuration check outside timestamp conditional.
  • Only calculates and applies delay when time remains to wait.
• Testing:
  • All existing tests pass.
  • Linting and type checking pass.
  • Manual testing confirms issue resolution.

^{This description was created by for 713e891. You can customize this summary. It will automatically update as commits are pushed.}

[roomote]

Reviewing my own code is like debugging in a mirror - everything looks backwards but the bugs are still mine.

[roomote]

Is this intentional? While checking for rateLimit > 0 correctly handles the undefined/0 case, what happens if someone accidentally configures a negative rate limit? Should we add validation to ensure rateLimit >= 0 or use Math.max(0, rateLimit) to be defensive?

[roomote]

Could we improve readability by combining these conditions? Something like:

Suggested change

	if (remainingDelay > 0) {
	if (Task.lastGlobalApiRequestTime && rateLimit > 0) {
	const now = Date.now()
	const timeSinceLastRequest = now - Task.lastGlobalApiRequestTime
	const remainingDelay = rateLimit * 1000 - timeSinceLastRequest
	rateLimitDelay = remainingDelay > 0 ? Math.ceil(remainingDelay / 1000) : 0
	}

This would eliminate the nested if statement while maintaining the same logic.

[roomote]

Minor suggestion: Consider renaming this variable to rateLimitSeconds to match the configuration property name (apiConfiguration?.rateLimitSeconds). This would make the code more consistent and self-documenting.