Add LM Studio provider (native /api/v1)

[jasonwarta]

Summary

• New LMStudioProvider targeting LM Studio's native REST API (/api/v1/models, /api/v1/chat) rather than the OpenAI-compat surface — so we get back tokens/sec, time-to-first-token, and model load time for diagnosing local-inference perf. Logged at debug level; doesn't leak LM Studio specifics into the provider-agnostic QueryResponse.
• Local providers (Ollama + LM Studio) now register unconditionally instead of being gated on a one-shot boot-time health check. A local server that was down at startup used to stay dropped for the entire MCP process lifetime — now list_models/ask_model reach out live on each call (backed by the existing 30s cache), so a LAN/local server coming online mid-session just works.
• 3s AbortController timeout on LM Studio healthCheck/listModels so a dead server can't stall list_models calls.
• Defaults to http://localhost:1234, override with LMSTUDIO_URL for LAN/remote instances.
• Filters non-chat models (e.g. embeddings) via the type field from /api/v1/models.
• Route explicitly with lmstudio/<model-key>; JIT-loading is delegated to LM Studio so not-loaded models load on first query.

Why the local-provider fix is in this PR

Hit the startup-only registration bug while testing (LAN LM Studio box was asleep at first boot; /mcp reconnect didn't respawn the process, had to claude mcp remove && add). Ollama has the identical pattern. Fixing only one would leave two different registration behaviors for conceptually identical providers, so both are fixed together. Cloud providers already register based on env-var presence alone, so this brings local in line with cloud.

Known limitations

• `/api/v1/chat`'s message-array input shape wasn't reverse-engineerable from error messages on the probed instance (string `input` works; the array form expects a content-part discriminator the schema doesn't advertise). `system_prompt` is prepended to the single-string input as a framed prefix — works correctly for single-turn prompts, which is all HydraMCP tools currently do.
• Context size is discovered from `loaded_instances[0].config.context_length` / `max_context_length`; we don't force a specific ctx on JIT load. Bump it in the LM Studio UI if you need larger ctx.

Test plan

• `healthCheck()` against live LM Studio on the LAN returns true
• `listModels()` returns 2 LLMs, filters out 1 embedding model via `type` field
• `query()` against `mistralai/codestral-22b-v0.1` — PONG response, usage/latency reported
• `query()` against `meta-llama-3.1-8b-instruct` — JIT-loads and responds, `model_load_time_seconds` captured
• `system_prompt` + `temperature` + `max_tokens` all honored by the native endpoint
• `npx tsc --noEmit` clean, `npm run build` clean
• End-to-end through MCP client: `list_models` shows lmstudio section with both models
• End-to-end through MCP client: `ask_model lmstudio/meta-llama-3.1-8b-instruct` → JIT-loads and responds in ~3.9s
• End-to-end through MCP client: `ask_model lmstudio/mistralai/codestral-22b-v0.1` → evicts llama, loads codestral, responds in ~7.5s (one-model-at-a-time LM Studio setup)

🤖 Generated with Claude Code