feat(providers): support DwarfStar (ds4) via openai-compatible backend strategy

[GiuseppePatane]

Summary

Adds support for DwarfStar (ds4) — antirez's native C inference engine for DeepSeek V4 Flash/PRO — through the existing openai-compatible provider type, with a dedicated backend strategy for context-window detection.

ds4 speaks the same protocol as every other OpenAI-compatible backend: same chat client, same endpoints, endpoint-only auth (ds4-server enforces no token), native tool_calls. The only real difference is metadata shape — /v1/models emits OpenRouter-shaped context_length / top_provider.context_length, fields neither the vLLM strategy (max_model_len) nor the llama.cpp strategy (meta.n_ctx / /props) reads. Without dedicated parsing, the context window — ds4's defining feature, long contexts backed by compressed KV cache on SSD — would never be auto-detected and compaction would size against a default.

Note on branch history: the first iteration added ds4 as a dedicated provider type (descriptor + plugin + resolver + DI wiring + TUI picker row). Review concluded the capability resolver's strategy chain is the seam built for exactly this case, so the provider type was removed and replaced by a strategy. The removal and the replacement are separate commits for reviewability.

Changes

• Ds4BackendStrategy in the openai-compatible resolver chain (vLLM → ds4 → llama.cpp → generic)
  • Matches on owned_by: "ds4.c" — exact vendor marker verified against ds4_server.c, mirroring the vLLM owned_by check
  • Reads context_length, falling back to top_provider.context_length
  • Reports text-in/text-out modalities (ds4 is text-only, and its model ids are not HuggingFace ids, so downstream resolvers have nothing to fill in)
  • Ordered before llama.cpp so a proxy answering /props in front of ds4 cannot steal the match
• Descriptor probe fallback: OpenAiCompatibleDescriptor.TryReadContextWindow now also reads the OpenRouter-shaped fields, so the model picker shows the context window for any backend emitting them
• Discoverability: picker row display name is now llama.cpp / vLLM / ds4
• Docs & skills: README, SPEC-008, docs/spec/configuration.md example (Type: "openai-compatible", endpoint http://127.0.0.1:8000), netclaw-operations skill row updated + version bump per the System Skills Sync Rule

Unrelated CI fix riding along

• Transitive pin MessagePack 2.5.301 (GHSA-hv8m-jj95-wg3x, pulled at 2.5.192 by Aspire 13.4.x in the samples). The advisory was published mid-PR and breaks restore on every branch under warnings-as-errors — worth cherry-picking to dev independently of this PR.

Testing

• Ds4BackendStrategyTests: match on owned_by, non-match for other vendors/missing model, top-level and nested context fields, missing-context → null
• Resolver dispatch test: ds4 shape wins over llama.cpp even with a /props response present
• Descriptor probe theory rows for both OpenRouter-shaped fields
• Build clean (0 errors / 0 warnings), Netclaw.Daemon.Tests 698/698, Netclaw.Cli.Tests 790/790, dotnet slopwatch analyze 0 issues
• Smoke: provider-add tape green (SMOKE_RID=osx-arm64). init-wizard tape fails only on a host-environment leak (the wizard detects the developer machine's ~/.claude/skills and shows an extra External Skills screen) — unrelated to this change; provider/endpoint/model steps pass.

Usage

# ds4-server running on its default port
netclaw provider add ds4 openai-compatible --endpoint http://127.0.0.1:8000
# model ids: deepseek-v4-flash / deepseek-v4-pro — context window auto-detected

[Aaronontheweb]

The ds4 plugin uses the same chat client, same endpoints, same auth, and same tool calling as openai-compatible — the only difference is which JSON field name holds the context window in the /v1/models response. Can this just be a new backend strategy on the existing openai-compatible provider instead of a whole new provider type?