fix: classify 429 overloaded messages as overloaded instead of rate_limit

[boticlaw]

Problem

In `classifyFailoverReasonFromHttpStatus()` (`src/agents/pi-embedded-helpers/errors.ts`), HTTP 429 responses are classified unconditionally as `rate_limit` without checking the error message body.

Current behavior

```typescript
if (status === 429) {
return "rate_limit"; // No message check
}
```

Fix

HTTP 429 now checks for overloaded messages via `isOverloadedErrorMessage()` before classifying, mirroring the pattern already used for 503 (line ~418) and 499 (line ~424):

```typescript
if (status === 429) {
if (message && isOverloadedErrorMessage(message)) {
return "overloaded";
}
return "rate_limit";
}
```

Why

Some providers (e.g., z.ai / ZhipuAI) return HTTP 429 with messages like:

"The service may be temporarily overloaded, please try again later"

This is a server capacity issue, not a consumer rate limit. Misclassifying it:

• Inflates `failureCounts.rate_limit` in telemetry, hiding real rate limit issues
• Breaks semantic correctness (overloaded != rate_limit)
• Will cause incorrect behavior if these failure reasons get divergent handling (e.g., different cooldown strategies)

Diff

```diff
if (status === 429) {

• if (message && isOverloadedErrorMessage(message)) {

• return "overloaded";
  

• }
  return "rate_limit";
  }
  ```