bug: .env nested keys ignored and stale wiki model bindings break OpenAI-compatible providers

[shsaihdsaiudh]

Summary

Two related problems when configuring OpenAI-compatible providers (e.g. DeepSeek) purely through .env:

1. .env nested/array keys are never bound

LoadEnvFile adds .env keys to the in-memory configuration with their raw names, so the standard environment-variable form for nested/array config (RepositoryAnalyzer__AllowedLocalPathRoots__0) does not map to RepositoryAnalyzer:AllowedLocalPathRoots:0. Also, .env.example documents LOCAL_IMPORT_ROOT, but the code never reads that variable.

Impact: submitting a local directory fails with 当前未配置允许导入的本地目录根路径 even when the whitelist is set in .env. Workaround: set a real process environment variable before startup.

2. Stale wiki model bindings are never repaired

UpsertSettingAsync only repairs *_PROVIDER_ID settings, never *_MODEL_ID settings. On a fresh install, SystemSettingDefaults seeds WIKI_CATALOG_MODEL_ID=gpt-5-mini and WIKI_CONTENT_MODEL_ID=gpt-5.2. When a non-OpenAI provider (e.g. DeepSeek) is configured through legacy env vars, the migration cannot overwrite these stale model IDs, and wiki generation fails with:

AI model 'gpt-5-mini' is not available for provider '...'

Environment

• OpenDeepWiki main (2026-08-06)
• Native .NET 10 run on Windows (also reproducible with Docker)
• DeepSeek API via https://api.deepseek.com/v1, model deepseek-v4-flash

Expected behavior

• .env nested keys (__ form) and LOCAL_IMPORT_ROOT should take effect.
• Wiki generation should either use the model configured in env vars or fall back to the provider's default model instead of failing on a stale seeded model ID.

Proposed fix

See PR #384 (normalize .env keys, map LOCAL_IMPORT_ROOT, repair stale model bindings during migration).