feat: Missing ACP/Multica daemon long-running protocol support (blocking integration)

[lithinkit]

Body:
Describe the bug/blocker
This is not a bug, but a missing protocol feature that prevents DSH from being discovered and managed by external daemons like Multica (v0.4.32).

Current state:

DSH installed: v0.1.1-rc.2 (global)

Available modes: headless (one-shot) and web (browser UI).

Missing: ACP (Agent Communication Protocol) server mode or a persistent JSON-RPC/WebSocket interface similar to Hermes (acp) or Opencode (run --json).

Impact:
Multica daemon has supported DSH since v0.4.26, but it cannot discover or maintain a session with DSH because DSH lacks a long-lived service endpoint. The client side is ready, but the server-side handshake is missing.

Request:
Please add an acp subcommand (or a --daemon flag) that exposes a standard protocol interface, allowing process supervisors like Multica to spawn and communicate with DSH persistently.

Workaround (temporary):
Currently only dsh --headless "cmd" is viable, which loses context and state.

[PerryLink]

Delivered — ACP support has shipped. The repository now has a dedicated automation ACP v1 server package, @deepseek-ai/dsh-acp (packages/acp/acp), speaking the standard Agent Client Protocol over JSON-RPC stdio with persistent sessions: create/resume, model + reasoning-effort selection, MCP server attachment, submit/cancel, semantic updates, and independent close (packages/acp/acp/README.md).

Start it with pnpm dsh --profile acp; the in-repo client is dsh-subagent-acp (README.md:12). Get it by updating to the latest release (npm latest = 0.1.5-rc.1) or pulling master — it ships in the normal distribution, no separate plugin install.