fix(custom-model): root-cause and fix DeepSeek's HTTP_404 (missing /v1)

DeepSeek Harness's own bundled provider module
(@deepseek-ai/dsh-llm-deepseek) builds its request URL as
`${DEEPSEEK_BASE_URL}/chat/completions` with no `/v1` insertion of its
own (its real public API, https://api.deepseek.com, expects the
caller's base URL to already carry any needed prefix), while
llama-swap/llama.cpp only ever serves the OpenAI-conventional
`/v1/chat/completions`.

Confirmed two ways:
- Installed the real @deepseek-ai/dsh package (all its actual
  published dependencies) into a scratch dir purely to read
  dsh-llm-deepseek's source: `fetch(`${connection.baseURL}/chat/
  completions`, ...)`, baseURL read straight from DEEPSEEK_BASE_URL —
  the same grep-the-real-source bar pi/grok's fixes were held to.
- Live against the test-picker's llama-swap: `POST <baseUrl>/chat/
  completions` -> 404, `POST <baseUrl>/v1/chat/completions` -> 200,
  same endpoint. dsh's own error template ("DeepSeek API error (HTTP
  ${status})") reproduces the originally-reported
  "dsh: HTTP_404: DeepSeek API error (HTTP 404)" exactly.

- New registry field `appendV1Suffix` (env kind only, deepseek's entry
  alone — claude/gemini must NOT get it, since claude was already
  confirmed working against the unmodified baseUrl). When set,
  buildCustomModelInjection runs endpoint.baseUrl through the same
  withV1Suffix() helper configDir-kind CLIs (pi/grok/codex) already
  use, instead of writing it verbatim.

Not yet re-run end-to-end through a real dsh binary — no install
available in this environment (not in PATH, and the test-picker
container doesn't bundle it) — so this is source-confirmed and
live-verified at the HTTP level, not yet promoted to "verified"
alongside claude/opencode/pi/grok/omp. Docs (custom-model-endpoints.md,
the plan doc's confidence table, the wiki page, CLAUDE.md) all updated
to reflect this precisely rather than leaving the old "root cause not
identified" claim in place.

2 new/updated tests for the /v1 suffix (including idempotency against
a baseUrl that already ends in /v1) plus a corrected mock-server
contract test. Typecheck/lint clean; full suite shows no new
regressions.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RqZeHrRS6DYcGcGX2p9EwG

docs/custom-model-endpoints.md

@@ -482,8 +482,23 @@ for '<id>' not found. Defaulting to fallback metadata...` on launch —
   `GOOGLE_GEMINI_BASE_URL` is set. Unresolved after real investigation
   (several auth workarounds were tried and ruled out); do not rely on
   Gemini support yet.
-- **DeepSeek** — the request reaches the server (env vars are read) but
-  gets a consistent `HTTP_404`. Root cause not identified; best-effort only.
+- **DeepSeek** — root cause of the `HTTP_404` found and fixed. DeepSeek
+  Harness's own bundled provider module (`@deepseek-ai/dsh-llm-deepseek`)
+  builds its request URL as `${DEEPSEEK_BASE_URL}/chat/completions` with no
+  `/v1` insertion of its own (its real public API, `https://api.deepseek.com`,
+  expects the caller's base URL to already carry any needed prefix) —
+  confirmed by reading its own source and, live, that
+  `POST <baseUrl>/chat/completions` 404s against llama-swap while
+  `POST <baseUrl>/v1/chat/completions` succeeds; the harness's own error
+  template (`DeepSeek API error (HTTP ${status})`) matches the originally
+  reported symptom exactly. `customModelInjection`'s new `appendV1Suffix`
+  (deepseek's entry only — claude/gemini must NOT get it, since claude was
+  already confirmed working against the raw `baseUrl`) fixes it by writing
+  `DEEPSEEK_BASE_URL` with `/v1` appended. Not yet re-run end-to-end with a
+  real `dsh` binary (no install available in this environment) — the fix
+  is source-confirmed and live-verified at the HTTP level, but a real
+  "hello world" reply through `dsh` itself is still outstanding before
+  calling this fully verified like the harnesses above.
 - **Antigravity** — no known custom-endpoint mechanism at all; unsupported.
 
 See the confidence table in `custom-model-endpoints-plan.md` for the full detail behind