feat: add lmstudio provider to setup wizard

[rakaarwaky]

Summary

LM Studio is a popular local LLM server that runs an OpenAI-compatible API on http://localhost:1234/v1. It was previously only reachable through the wizard's Custom provider, which has a documented history of producing malformed base_url values — typically http://127.0.0.1:1234/api/v1/ — that double the /v1 segment. backend.llm_client.LLMClient constructs the request URL as {base_url}/v1/models (line 292), so a base URL ending in /api/v1/ resolves to the non-existent …/api/v1/v1/models and the connection silently fails (the wizard's test_connection masks this because it uses rstrip("/") rather than rstrip("/v1"), so it still sees a 200 on a slightly-wrong path).

This PR adds lmstudio as a first-class entry in PROVIDER_DEFAULTS with the canonical base URL http://localhost:1234/v1, so the setup wizard (both the evonic setup CLI and the /api/setup web flow) surfaces it next to ollama and llama.cpp.

Changes

• backend/setup.py — add lmstudio entry to PROVIDER_DEFAULTS:
  • type: local
  • base_url: http://localhost:1234/v1
  • api_key_required: False (LM Studio's local server is unauthenticated by default)
  • label: "LM Studio", description: "Local · no API key needed"
  • placeholder_model: "lmstudio" (LM Studio has no fixed placeholder name; the wizard fetches the real list via /v1/models on first save)
• unit_tests/test_setup_lmstudio_provider.py — new regression test that:
  1. Pins the entry's shape (registered, base URL is canonical, no key required, marked local, has all required keys).
  2. Runs a live test_connection() probe against localhost:1234 and skips gracefully if no LM Studio server is reachable, so CI stays green in environments without one installed.

Testing

• /home/raka/.evonic/venv/bin/python -m unittest unit_tests.test_setup_lmstudio_provider -v → 6/6 pass (5 shape pins + 1 live probe against the running LM Studio on this host).
• Reproduced the original failure mode on the previous main by creating a model with base_url: http://127.0.0.1:1234/api/v1/; confirmed that after the fix, users selecting the new LM Studio entry land on the correct …/v1 path.

Scope

2 files, 8 LOC of production code + a 175-LOC regression test. No schema migration, no API changes, additive only — the Custom provider is untouched for users who still want to point at non-default LM Studio ports or remote instances.

Notes for reviewer

• The original symptom (LM Studio not connecting) is fixed indirectly: the wizard now offers the right URL, eliminating the human error that produced the malformed /api/v1/ path in the first place. A separate hardening — making test_connection use rstrip("/v1") so it fails loudly on malformed URLs — is intentionally out of scope for this PR; happy to follow up if useful.
• The placeholder_model is "lmstudio" rather than a real LM Studio model name (e.g. qwen2.5-7b-instruct) because LM Studio's model identifiers are user-chosen and the wizard fetches the real list on save.