[Enhancement] Structured error categorization and retry logic

[OneStepAt4time]

Summary

Aegis returns generic error objects across all endpoints. Claude Code categorizes errors into UserError, ToolError, and SystemError with retry logic, error codes, and actionable messages.

CC Reference

• src/utils/errors.ts — Error class hierarchy
• src/utils/toolErrors.ts — Tool-specific error formatting
• src/services/tools/toolHooks.ts — Error handling in tool execution flow
• src/types/permissions.ts — PermissionError types

CC Architecture

• Error hierarchy: UserError (user input), ToolError (tool execution), SystemError (infrastructure)
• Each error has: code, message, retryable, suggestions[], context{}
• Tool errors include the tool name, input, and whether the output can be modified by hooks
• Permission errors carry decisionReason and blockedPath

Current Aegis Gap

• Aegis uses plain {error: string, code?: number} responses
• No error codes — callers cannot programmatically distinguish error types
• No retry guidance — callers do not know if retrying makes sense
• No suggestions — callers get no hints on how to fix the error

Proposed Implementation

1. Define AegisError hierarchy: SessionError, PermissionError, TmuxError, ValidationError, InternalError
2. Each error has: code (string enum), retryable: boolean, suggestions: string[]
3. Standardize error responses across all REST endpoints
4. Add error codes to WebSocket messages
5. Update API docs with error code reference

Priority

P3 — DX improvement, not blocking