[BUG] Raw Go error messages leak to end users in chat

[rahul-hudle]

Description

When the LLM call fails, the raw Go error chain is sent directly to the user in chat. Users see internal error details like HTTP status codes, wrapped error contexts, and Go error formatting.

Current Behavior

Error processing message: LLM call failed after retries: status 401: Unauthorized

This appears in Telegram, Discord, Slack, and all other channels.

Expected Behavior

Users should see a friendly, actionable message:

• Auth errors: "I couldn't process that — please check your API key in ~/.picoclaw/config.json"
• Rate limits: "I'm being rate-limited. Please try again in a moment."
• Network errors: "I couldn't reach the AI provider. Check your internet connection."
• Generic: "Something went wrong. Run 'picoclaw doctor' to diagnose."

Raw errors should be logged server-side only.

Location

• pkg/agent/loop.go:161 — response = fmt.Sprintf("Error processing message: %v", err)

Fix

Add an error classification layer between the agent loop and the user-facing response. Map common error types (401, 429, network timeout, context exceeded) to friendly messages. Log the full error with logger.ErrorCF.

[nikolasdehor]

This is a significant UX issue. Leaking raw Go errors to end users is both confusing and a potential information disclosure risk (internal paths, error chains, HTTP status codes).

The fix location is pkg/agent/loop.go where fmt.Sprintf("Error processing message: %v", err) is sent directly to the channel. The error classification layer already partially exists in pkg/providers/error_classifier.go — it just needs to be wired into the user-facing response path.

Suggested implementation:

func userFriendlyError(err error) string {
    var apiErr *APIError
    if errors.As(err, &apiErr) {
        switch {
        case apiErr.StatusCode == 401:
            return "Authentication failed. Please check your API key in config.json."
        case apiErr.StatusCode == 429:
            return "Rate limited by the AI provider. Please try again in a moment."
        case apiErr.StatusCode == 413 || strings.Contains(apiErr.Message, "context"):
            return "Message too long for the model's context window. Try a shorter message."
        case apiErr.StatusCode >= 500:
            return "The AI provider is experiencing issues. Please try again later."
        }
    }
    if errors.Is(err, context.DeadlineExceeded) {
        return "Request timed out. The model may be overloaded."
    }
    return "Something went wrong processing your message. Check logs or run 'picoclaw doctor'."
}

The raw error should still be logged via logger.ErrorCF for debugging. Only the friendly message goes to the user.

This pairs well with #629 (retry logic) — the friendly message should only be shown after retries are exhausted.