[FEATURE] Unified TRANSIENT/PERMANENT/UNKNOWN error taxonomy

[koydas]

🎯 Goal

Add a feature that addresses a clear product need.

📍 Context

• Repo: autonomous-dev-loop
• Domain: Pipeline reliability
• Component: scripts/lib/* (error handling + external clients)

🚀 Description

Introduce a shared error taxonomy (TRANSIENT, PERMANENT, UNKNOWN) used across modules calling external services (LLM, GitHub API).

Value: consistent retry/fail-fast decisions and reduced behavioral drift across scripts.

Current state:

• groq_client.mjs retries on 429 only — 5xx is not retried.
• anthropic_client.mjs has no retry at all.
• llm_client.mjs falls back to secondary provider on any error, including permanent 4xx (e.g. invalid API key). This is a correctness bug: a 401 should fail fast, not trigger provider fallback.

🧩 Scope

• In:
  • Create a shared error classification module.
  • Explicitly map known cases (timeout, 429, 5xx, business 4xx, invalid payload).
  • Expose a simple API consumed by existing clients.
  • Fix llm_client.mjs to only fall back on TRANSIENT errors.
• Out:
  • Full refactor of unrelated scripts.

🧪 Acceptance criteria

• Functional
  • Errors are deterministically classified according to documented rules.
• Edge cases covered
  • Ambiguous cases (UNKNOWN) are explicitly handled.
  • llm_client.mjs does NOT fall back on 401/403/400.
• Tests included
  • Unit tests for 429/5xx/timeout/4xx/invalid payload classification.

⚙️ Constraints

No heavy new dependencies; keep API minimal and stable.

[github-actions]

✅ Issue Validation Report

Field	Value
Status	VALID — ready for development
Score	100/100 [██████████]

💡 Suggested Acceptance Criteria

Copy the block below and paste it into the issue description, then save. Saving will re-trigger validation automatically.

## Acceptance Criteria

- [ ] Given a 429 status code, the classifier returns `TRANSIENT` and triggers retry logic
- [ ] Given a 500 status code, the classifier returns `PERMANENT` and does not trigger retry logic
- [ ] Given a 401 status code in `llm_client.mjs`, the fallback to secondary provider is explicitly disabled
- [ ] The `UNKNOWN` classification is applied to unhandled error types and logs a warning with stack trace
- [ ] Unit tests verify classification for timeout errors (ETIMEDOUT), 400-series business errors, and invalid JSON payloads