fix(acp): dead-letter auth errors immediately with re-auth hint

[wpfleger96]

Problem

Auth-class errors (expired OAuth token, HTTP 401) are non-retryable: the token won't self-repair between attempts. Today, PromptOutcome::Error for an application-class error falls into the generic queue.requeue() path, burning up to 10 retry slots over a long backoff window before dead-lettering. Will's canary run observed the 401 message being retried repeatedly.

Solution

Add is_auth_error() that classifies AcpError::AgentError messages matching two narrow patterns observed in the field:

• "Re-authenticate" — emitted by the Claude CLI for expired OAuth tokens
• "API Error: 401" — present in Claude/Codex HTTP-401 responses

Conservative matching is intentional: a false positive (misclassifying a transient error as non-retryable) silently drops a user message, which is worse than a false negative (extra retries on an auth error).

In handle_prompt_result, a new branch intercepts the failing batch before queue.requeue() for auth-class errors and dead-letters immediately, posting a user-visible notice to re-authenticate the CLI (e.g. claude /login or codex login).

The transport/application split in PromptOutcome::Error is untouched — this only changes batch fate after an application-class auth error.

Tests

6 new tests in error_outcome_emission_tests:

1. is_auth_error matches Re-authenticate message
2. is_auth_error matches API Error: 401 message
3. is_auth_error rejects other AgentError messages (usage credits, etc.)
4. is_auth_error rejects transport errors (I/O, WriteTimeout)
5. Auth error dead-letters immediately — 0 pending channels after handle_prompt_result
6. Non-auth application error still requeued — 1 pending channel after handle_prompt_result

Full cargo test -p buzz-acp: 598/598 passing.