fix(providers): honour request_timeout for CLI providers with clear timeout errors and fallback

[securityguy]

Problem

The three CLI providers (claude-cli, codex-cli, gemini-cli) silently ignored the request_timeout field in model_list config. The factory created them without any timeout, so subprocesses ran indefinitely — a serious problem for agentic tasks (e.g. cron jobs) where a runaway session could block the agent loop forever.

Additionally, ClassifyError used == to match context.DeadlineExceeded, which does not match wrapped errors, so even if a timeout had been applied elsewhere it would not have triggered the fallback chain.

Fix

pkg/providers/factory_provider.go

When request_timeout > 0 in the model config, the factory now calls the new WithTimeout constructors for each CLI provider instead of the timeout-less defaults. A value of 0 (the default) leaves behaviour unchanged.

pkg/providers/{claude,codex,gemini}_cli_provider.go

Each provider gains a timeout time.Duration field and a NewXxxWithTimeout constructor. In Chat(), if timeout > 0 the incoming context is wrapped with context.WithTimeout before being passed to exec.CommandContext. When cmd.Run() fails and ctx.Err() == context.DeadlineExceeded, a descriptive error is returned (e.g. "claude cli timed out after 30s") that wraps context.DeadlineExceeded so the fallback chain can classify it.

pkg/providers/error_classifier.go

Changed err == context.DeadlineExceeded to errors.Is(err, context.DeadlineExceeded) so that wrapped timeout errors correctly classify as FailoverTimeout and trigger fallback to the next candidate in the chain.

Result

With request_timeout: 10 on claude-cli and codex-cli as a fallback:

• claude-cli is killed after 10 seconds
• The error message clearly states "claude cli timed out after 10s"
• The fallback chain automatically retries with codex-cli
• If all candidates time out, the user receives a meaningful error instead of "signal: killed"

Configuration

{
    "model_name": "claude-cli",
    "model": "claude-cli/claude-code",
    "request_timeout": 1200
}

Omitting request_timeout or setting it to 0 leaves behaviour unchanged — no timeout is applied.