feat(acp): ship an ACP bridge for DeepSeek Harness

[wgqqqqq]

What this does

Makes DeepSeek Harness work in BitFun the way codex / claude-code / opencode already do: a user installs dsh, picks a model inside it, and starts a session. BitFun stores no DeepSeek credentials and configures no DeepSeek models.

The harness ships no ACP entry point of its own. The published @deepseek-ai/dsh-acp is an automation surface — it deliberately withholds tool calls, reasoning, and mode selection, because a script does not need to watch an agent think. An IDE needs exactly those. So this adds packages/dsh-acp, an IDE-facing ACP server, and ships it as a dsh profile rather than as a package the user has to install separately.

Why a profile

A dsh profile is just a directory under $DSH_HOME/profiles/. On every launch the harness symlinks its whole dependency closure into $DSH_HOME/profiles/node_modules, so a profile resolves every @deepseek-ai/dsh-* plugin out of the user's own installation through ordinary Node parent lookup. BitFun therefore ships ~200KB of compiled bridge, not a second copy of the harness, and launches it as dsh --profile bitfun-acp.

The desktop bundle carries packages/dsh-acp/dist-profile as a Tauri resource; client/dsh_profile.rs materializes it into the user's dsh on first use, comparing a content stamp so it re-syncs only when the build changes.

Where the model and the key come from

cordis.yml mounts the harness's own dsh-settings-file, dsh-credentials-local, and dsh-agent-default-model rows. The model is whatever the user selected in dsh; the key is resolved per request from $DSH_HOME/.credentials.yaml (what dsh's Models page writes) with the usual .env and environment fallbacks. Nothing about an account is stored in this repository, and the bridge never asks for a key of its own.

Relationship to #2272

This replaces the dsh preset added in #2272, keeping the id dsh. That preset launches @deepseek-ai/dsh-acp-demo, which is the automation surface described above: no tool cards, no reasoning, no mode picker, and a hand-written --config path. The two cannot coexist under one id, and offering the user two DeepSeek entries that differ in ways they cannot see would be worse than picking one.

Also in this PR

Two changes that are not dsh-specific — they were needed to make a dsh session look right, and they apply to every ACP agent:

• Native tool cards (tool_card_bridge/, stream.rs, +534): ACP tool calls render as BitFun's own Bash / Read / Edit cards instead of generic blobs, with results and reasoning grouped by round.
• ACP mode picker (ModelSelector.tsx, +423): an agent may publish models, a mode config option, or both. The picker now handles all three, and collapses to a single disabled entry with a reason once a conversation has started and its mode is fixed.

Happy to split these out if you would rather review them separately.

Closing a session and opening it again

A reopened ACP session was blank, and its mode picker had unlocked and reverted to the default. Three separate causes, all fixed here; the first two are not dsh-specific either.

The turns never reached disk. The projection is the only writer of an ACP turn, but it had no storage slot to write into — that slot arrives with the backend's DialogTurnStarted, and nothing in the local runtime starts a turn an external agent runs, so every save was deferred forever. The projection now allocates the slot itself, and declines to guess when guessing would overwrite history.

The backend refused the save it did get. save_persisted_dialog_turn validates a turn against the runtime's history branch for that session, and an externally driven session has none, so a first turn failed with OutcomeUnknown. It now persists straight through for a session whose provider metadata says an external agent owns it; a runtime-owned session still needs its branch, pinned from both sides by a new test. The desktop path also stopped loading such a session into the session manager first, which restored nothing and rewrote its persisted mode to a local fallback.

The bridge never advertised loadSession, so BitFun had only session/new to fall back on — every stored session in my install carries acpResumeStrategy: "new" for that reason. packages/dsh-acp now implements session/load: a cold session resumes out of the harness's own persistence and replays its history, the mode comes back from the session's own log rather than the roster (so a conversation reopens under the preset it was written under, however the default has moved) and is locked once the conversation has started, and a load is refused for a session that was never stored or that belongs to another directory.

Build

packages/dsh-acp is deliberately not a pnpm workspace member. It pins the whole harness 0.1.0-rc.6 train and carries its own package-lock.json, so installing the harness is the desktop bundle build's cost rather than every contributor's pnpm install. scripts/prepare-dsh-profile.mjs runs npm ci + tsc + the profile packaging as part of frontend:build-all, and fails the build on error — an app that silently ships no bridge is indistinguishable from a working one until a user starts a session. BITFUN_SKIP_DSH_PROFILE=1 opts out on purpose.

One note for anyone touching the pins: half of these packages still carry an npm latest of 0.0.1-rc.1 while next points at 0.1.0-rc.6. An unpinned install mixes the two trains and disagrees with itself; that is why every version here is exact.

Verification

• Clean-room build: npm ci → tsc → profile packaging in an empty tree, from the registry alone, no local harness checkout.
• The built profile materialized under a real dsh install: handshake, session/new, three modes offered, then a full turn with streamed reasoning, a bash tool call, its result, and end_turn — with the key only in $DSH_HOME/.credentials.yaml.
• The same profile driven through session/load against that install: loadSession advertised, a stored conversation replayed as user message → reasoning → tool cards → assistant text, and one locked mode returned.
• packages/dsh-acp: 30 vitest tests, tsc --noEmit clean. Fixed one flaky test that waited on the event count rather than on the notification it was asserting about (~1 failure in 6 full-suite runs).
• cargo test -p bitfun-acp (136), the new product_runtime persistence test, cargo check -p bitfun-desktop, rustfmt on the touched files and cargo clippy on the touched crates (no new warnings); web-ui vitest suite; tsc --noEmit.

Remote workspaces

A remote / SSH workspace materializes the same profile on the remote host: one probe round trip reads $DSH_HOME, the harness version, and the installed stamp there, and when the stamp does not match this build the profile goes over as a single tar stream on the session's own transport — not SFTP, so container connections are covered too. The remote host supplies dsh, the model, and the key, exactly as a local one does; if dsh is missing or too old there, the launch fails with that sentence instead of with a missing-profile error from the launcher.