fix: honor timeout_seconds on the Anthropic declarative provider

[JAManfredi]

Problem

The declarative custom-provider spec exposes a timeout_seconds field, and the OpenAI engine reads it:

// crates/goose-providers/src/openai.rs
let timeout_secs = config.timeout_seconds.unwrap_or(DEFAULT_TIMEOUT_SECONDS);
let mut api_client = ApiClient::with_timeout_and_tls(host, auth, Duration::from_secs(timeout_secs), tls_config)?;

The Anthropic engine's from_declarative_config did not — it built its client with ApiClient::new_with_tls, which hardcodes the 600s ApiClient default and never reads config.timeout_seconds:

// crates/goose-providers/src/anthropic.rs (before)
let mut api_client = ApiClient::new_with_tls(config.base_url, auth, tls_config)?;

So an integrator setting timeout_seconds on an Anthropic-engine custom provider silently got 600s regardless of the configured value. This matters when the provider sits behind a proxy where the desired request-timeout differs from 600s (e.g. to fail-and-retry a stalled upstream read faster than the 10-minute default).

Fix

Read config.timeout_seconds and pass it through ApiClient::with_timeout_and_tls, mirroring the OpenAI engine. Falls back to 600s when unset, so behavior is unchanged for providers that don't set the field.

Testing

• Added ApiClient::timeout() accessor (mirrors the existing host() getter) so the built client's timeout is inspectable.
• Two tests in anthropic_def: an explicit timeout_seconds is honored (120s), and the default (600s) is applied when the field is unset.
• cargo test -p goose --lib providers::anthropic_def — 4 passed. cargo fmt --check and cargo clippy -p goose-providers clean.