bug(retain): per-scope retain timeout does not propagate to the underlying provider implementation

Summary

In live 0.8.3-slim deployment, retain-specific timeout configuration was resolved correctly at the config layer but did not reach the actual provider implementation used to execute retain_extract_facts.

Expected behavior

If HINDSIGHT_API_RETAIN_LLM_TIMEOUT=300, retain fact extraction should actually run with that effective timeout.

Actual behavior

Retain still failed as if the effective timeout were 120.0s, with logs shaped like:

LiteLLM call exceeded timeout=120.0s

That happened even though the runtime env had HINDSIGHT_API_RETAIN_LLM_TIMEOUT=300.

Live evidence

From the live recovery draft and notes:

• env: HINDSIGHT_API_RETAIN_LLM_TIMEOUT=300
• symptom log: LiteLLM call exceeded timeout=120.0s
• after local propagation fix: retain no longer showed new 120.0s failures and the workload advanced into storing/commit

Detailed draft source:

• 2026-06-25-hindsight-llm-config-audit/artifacts/upstream-issue-draft-retain-timeout-provider-impl.md

Why this matters

This is not just a generic timeout problem. The retain-specific timeout was configured, but the effective timeout used by the provider stayed at the older/default cap, causing repeated retries and token burn.

Local recovery shape

The local hotfix propagated the resolved timeout into the real underlying provider object used by the wrapper during retain calls, instead of only carrying the value on the outer config/wrapper layer.

Version

Observed on live ghcr.io/vectorize-io/hindsight:latest-slim / 0.8.3-slim runtime.