Correct the DeepSeek binding terminology: it is a compatibility pairing, not DeepSeek's first-party harness #660

Part of #653. Rescoped: the schema half of the original issue is struck (see below); what remains is a terminology-accuracy fix.

Problem

The shipped tree asserts, in its most visible surfaces, that Claude Code is DeepSeek's official / supported coding-agent integration:

• the root ultrafuzz.toml comments on the opt-in DeepSeek profile, which docs/config.md calls the default root config;
• the class comment in packages/runtime/src/templates/smithers/agents/deepseek.tsx.

The already-merged research page under docs/explanation/ establishes the opposite: DeepSeek's first-party harness is DeepSeek Harness (dsh), listed first under Agent Integrations in DeepSeek's own API documentation, and what ultrafuzz ships is Claude Code pointed at DeepSeek's Anthropic-compatible endpoint — a compatibility pairing. The research page names this exact failure mode: the risk is that the harness and the provider get treated as a single selection. Calling one vendor's harness another vendor's official integration is that treatment.

This has to be corrected before any real dsh binding exists (#661), so the two never share a name or a claim.

Scope

• Reword the DeepSeek profile comments in the root ultrafuzz.toml and the class comment in the DeepSeek adapter template to say: this runs the Claude Code harness against DeepSeek's Anthropic-compatible endpoint — a compatibility pairing, not DeepSeek's first-party coding agent.
• Add one short paragraph to the DeepSeek section of docs/config.md saying the same, and noting the pairing is opt-in and non-default.
• Fold in the residual editorial half of Document the provider/harness pairing policy and migration paths #664: docs/config.md should not present a single provider+harness combination as the only possible architecture, and should state default-selection status explicitly rather than by omission.

Explicitly out of scope (struck)

• Expressing this as harness = "claude-code" + provider = "deepseek" in a new schema. That is the parallel provider/harness config-and-validation surface rejected in PR feat(config): add provider harness binding validation #682.
• Renaming the DeepSeekAgent ref/export. It would require alias plumbing across the config package, the doctor's agent-to-binary map, Modal defaults, the workspace config, the benchmark manifest and the lane definitions — churn with no behavioural or documentation gain.

Acceptance criteria

• No shipped comment, config file, or doc page calls Claude Code DeepSeek's official/supported/first-party coding-agent integration.
• The DeepSeek pairing is described as a compatibility pairing wherever it is introduced.
• docs/config.md states which pairing is the default and that others are opt-in.
• Zero code, schema, or runtime behaviour changes.