feat: exponential backoff on HTTP 429 (re-impl of #90)

[jliounis]

Summary

Re-implementation of the rate-limit retry portion of the previously-closed #90. Credit: @akshayabogoju-coder for the original proposal.

Why

Today, makeApiRequest fails immediately on HTTP 429. That makes the server flaky under bursts and propagates a hard failure to the MCP client for what is almost always a transient condition.

Change

makeApiRequest now wraps the underlying HTTP call (extracted as singleApiAttempt) in a retry loop:

• Retries only on HTTP 429. Other 4xx/5xx fail fast — we can't assume idempotency without operator-controlled idempotency keys, and Perplexity does not signal retry-safe 5xxs distinctly.
• Schedule: [2s, 4s, 8s] by default (3 retries, 4 attempts total).
• Respects Retry-After when present. The actual wait is max(configured-delay, retry-after-seconds * 1000) so the server never retries faster than the API asks.
• Overridable via PERPLEXITY_RETRY_DELAYS_MS (comma-separated milliseconds) for tests and ops tuning.

Scope notes

This PR is intentionally narrower than the original #90:

• Does not touch HTTP transport / 0.0.0.0 binding / origin controls (separate security review).
• Does not add a README "Professional Contributions" section (out of scope).
• Does not remove args: any casts in tool handlers — the MCP SDK already enforces the Zod inputSchema before the handler runs, so the cast is cosmetic, not a safety hole. Worth its own cleanup PR if/when the SDK's handler generics stabilize.
• The CWE-200 error-message sanitization that feat: implement production-grade resilience and strict zod validation #90 also touched ships separately as #107 to keep review scopes clean.

Tests

• npm test: 82 passed / 82 (was 78 on main).
• 4 new tests in a "HTTP 429 retry behavior" suite:
  • success after N transient 429s (3 attempts, last succeeds)
  • gives up after the configured retry count (4 total attempts)
  • does not retry non-429 errors (5xx fails fast, 1 attempt)
  • Retry-After header is honored
• Tests use PERPLEXITY_RETRY_DELAYS_MS=0,0,0 to avoid real waits.
• npm run build: clean.

Backward compatibility

• Successful first attempts behave identically (no extra latency).
• Non-429 error messages are unchanged.
• The new env var (PERPLEXITY_RETRY_DELAYS_MS) is opt-in; defaults to the 2s/4s/8s schedule that matches the original proposal.

[akshayabogoju-coder]

Thanks for refining the scope and driving the implementation, James—appreciate the credit.