feat: add optional OpenAI-compatible translation engine

[daileychiotti-ai]

@

Summary

Adds an opt-in OpenAI-compatible API engine (OpenAI, DeepSeek, Ollama, any /chat/completions endpoint) alongside the existing free engines, for higher-quality, context-aware translation.

It is additive and off by default: TranslationProvider defaults to BuiltIn, so existing installs behave exactly as before. When the user picks OpenAI-compatible API in the control panel and fills in base URL / key / model, the LLM is tried first and the existing Google→MyMemory chain becomes the fallback — so a bad key, rate limit, or offline moment never leaves text untranslated.

What changed

• UserSettings: TranslationProvider enum + LlmBaseUrl / LlmApiKey / LlmModel.
• TranslationService: Configure(settings) + a per-string LLM call that fits the existing TranslateAsync contract, with graceful fallback to the built-in engines.
• Control panel: an engine picker and a collapsible API settings panel (base URL / key / model). The window now auto-fits its height.
• Theme: a ModernTextBox style matching the existing dark design.
• README: documents the optional engine.

The key is stored only in the existing %APPDATA%\WinLens\settings.json and sent only to the configured endpoint.

Related issue

None — happy to open a discussion/issue first if you prefer.

Type of change

• Bug fix
• New feature
• Documentation
• Refactor
• Chore / tooling

Checklist

• Builds with dotnet build -c Release (0 warnings, 0 errors)
• Tested the change manually — verified locally against a real OpenAI-compatible endpoint (DeepSeek); see the test report comment below for method and results.
• Updated docs / README where needed
• Commit messages follow Conventional Commits

---

🤖 Generated with Claude Code
@

[daileychiotti-ai]

Local test report

Tested the branch locally on Windows 11 against a real OpenAI-compatible endpoint (DeepSeek deepseek-v4-flash). Verification was log/endpoint-based rather than a visual UI pass:

• Release build: dotnet build -c Release → 0 warnings, 0 errors.
• Endpoint/request shape: the exact request TranslationService builds (model + messages, plus the DeepSeek-only thinking: disabled flag) returns a correct translation.
• Engine selected + valid key: a one-shot capture (--translate) produced a translated overlay with no llm … lines in %TEMP%\winlens.log — the LLM path ran end-to-end.
• Graceful fallback (invalid key): the same run with a bad key logged llm http 401 for every block and still produced a translated overlay — i.e. it fell back to the built-in Google/MyMemory engine, so a misconfigured key never leaves text untranslated.

Note: I couldn't capture a screenshot of the overlay itself (screen-capture tooling masked the app window), so overlay rendering is inferred from the run completing without errors. A quick visual check on your side would still be worthwhile. Happy to adjust anything — and glad to move this to a Discussion first if you'd prefer to scope the feature there.