litellm timeout fix incomplete: directProviderGeneration still dies at the 30s default on v3.0.4

## What happened

svelte-ui-components PR 468 (29 files, ~3.3k insertions) ran Yama v3.0.4 with `ai.timeout: "15m"` in its config and litellm as the provider. The review worked for ~37 minutes, then failed with the exact pre-fix signature:

```
[NEUROLINK:ERROR] Generate failed for litellm: {"name":"TimeoutError","message":"litellm generate operation timed out after 30000"}
[NEUROLINK:ERROR] [NeuroLink.directProviderGeneration] All providers failed {"triedProviders":["litellm"],"lastError":"[litellm] Request timed out: litellm generate operation timed out after 30000","responseTime":116278}
❌ Review failed: Failed to generate text with all providers. Last error: [litellm] Request timed out: litellm generate operation timed out after 30000
```

Run: https://github.com/juspay/svelte-ui-components/actions/runs/33039296492 (fresh `reopened` event, so the merge ref carried the v3.0.4 pin and the migrated `mcpServers.servers` config — this is not the stale-snapshot artifact of earlier retries, and it reproduced identically on a prior run of the same PR).

## Reading

The v3.0.4 fix (adding litellm to the bundled neurolink's `DEFAULT_TIMEOUTS.providers` / honoring the configured timeout) does not cover the `NeuroLink.directProviderGeneration` path: 30s is still applied there regardless of `ai.timeout`. Small generate calls fit under 30s so most of the review completes; the final large-diff synthesis call cannot, and after retries (`responseTime: 116278` ≈ 3 attempts × 30s + backoff) the whole review dies with no verdict — the worst outcome, since the 37 minutes of work are discarded.

## Ask

Thread the configured timeout through every generate path (directProviderGeneration included), or expose a provider-timeout override Yama sets explicitly on each call. A regression guard that asserts the effective timeout on the direct path would have caught this.

Start at NeuroLink.directProviderGeneration and the bundled neurolink DEFAULT_TIMEOUTS.providers handling, then trace how ai.timeout reaches each generate path. Reproduce the 30-second failure with the reported litellm configuration and add a regression guard showing that the direct path uses the configured timeout.

Written by the indexing model from the issue text.