fix: load nested .env keys and repair stale wiki model bindings

[shsaihdsaiudh]

Summary

Fixes #385

Two fixes that make .env-driven setups with OpenAI-compatible providers (e.g. DeepSeek) work reliably:

1. .env nested/array keys are now bound correctly

LoadEnvFile added .env keys to the in-memory configuration with their raw names, so nested keys written in the standard environment-variable form (RepositoryAnalyzer__AllowedLocalPathRoots__0) were never bound to RepositoryAnalyzer:AllowedLocalPathRoots:0. As a result, local-directory import failed with 当前未配置允许导入的本地目录根路径 even when the whitelist was set in .env.

This PR:

• Normalizes __ to : when loading .env into configuration.
• Maps LOCAL_IMPORT_ROOT to RepositoryAnalyzer:AllowedLocalPathRoots:0, so the documented .env.example variable actually takes effect.

2. Stale wiki model bindings are repaired during AI configuration migration

UpsertSettingAsync only repaired *_PROVIDER_ID settings, never *_MODEL_ID settings. On a fresh install with a non-OpenAI-compatible provider configured through legacy env vars, SystemSettingDefaults seeds WIKI_CATALOG_MODEL_ID=gpt-5-mini / WIKI_CONTENT_MODEL_ID=gpt-5.2, and the migration could not overwrite them. Wiki generation then failed with AI model 'gpt-5-mini' is not available for provider ....

This PR:

• Allows model binding settings to be repaired when the bound provider no longer has the stored model (valid admin-chosen model bindings are preserved).
• Falls back to the provider's DefaultModelId (instead of hardcoded gpt-4o-mini) when no model is specified in legacy env vars.

Test plan

• Added MigrateAsync_RepairsStaleModelBindingsButKeepsValidOnes.
• Existing AiProviderPresetSeederTests suite passes (7/7).
• Manually verified end-to-end with a DeepSeek deepseek-v4-flash setup: .env local import whitelist works, and wiki catalog/content generation succeeds after migration.