feat(desktop): support MCP sidecars for custom harnesses

[fredamn76]

Summary

• persist an optional MCP sidecar command with custom harness definitions
• resolve built-in and custom MCP commands through the shared effective harness descriptor
• use the effective sidecar consistently for managed-agent summaries, process spawn, and restart hashing
• expose the optional command in the custom harness form with an availability check

Custom ACP harnesses currently lose the companion MCP server because Desktop derives it only from the built-in runtime catalog. The ACP process can start successfully, but the agent receives no custom tool server (and, for Buzz reply tooling, no authenticated companion).

This keeps the harness definition as the source of truth instead of restoring a stale per-agent snapshot field. Existing custom harness JSON remains compatible because mcpCommand is optional. Built-in runtimes retain their current catalog-derived MCP command, and the sidecar is started only for agents selecting the custom harness.

Related issue

Closes #3385.

Related: #3115 and #3227 cover provisioning and the broader app-agent installation model; this PR is limited to Desktop's custom-harness runtime contract.

Originating Buzz conversation:

• channel: recepie-mealie-mcp (34d45264-ea10-4065-82d6-831a43a90c84)
• thread root: 0907968b2234880045f1edd8dd8f8a22d4ed32b2e98294361094b9537e8e2ed8

Testing

Passed on the code tree now published as commit
ef41e584f78ec1d47fae2344352ee28531f3fcb0:

• just desktop-check
• just desktop-typecheck
• just desktop-build
• just desktop-test — 3908 passed
• just desktop-tauri-fmt-check
• pnpm -C desktop build:e2e
• playwright test tests/e2e/harness-catalog-screenshots.spec.ts --project=smoke — 1 passed
• git diff --check origin/main...HEAD

The original tested commit was rewritten only to replace a GitHub-blocked private
author email with the account's noreply address. Its tree hash is unchanged at
e443fb05f3bb857927f614cf730d505b5eab821c.

Not run locally: the full Tauri Rust test suite. This Linux machine does not have the GLib/GObject/WebKitGTK development packages required by Buzz's documented Tauri setup, and installing system packages requires administrator authentication. GitHub CI should exercise that gate.

Manual verification

1. Open Settings → Agent runtimes → Custom harness.
2. Enter an ACP command and an optional MCP command, then save.
3. Re-open the custom harness and verify both commands round-trip.
4. Assign an agent to the custom harness and start it.
5. Verify the managed-agent summary and startup log show the custom MCP command.
6. Change only the MCP command and verify the spawn hash triggers a restart.
7. Verify an agent on a built-in runtime still uses its catalog MCP default.

UI

Before/after screenshots are posted in the PR comments using the repository's screenshot helper.

[fredamn76]

Custom harness MCP sidecar

Before — a custom harness could configure only the ACP command:

After — an optional MCP command is available and explicitly scoped to agents using that harness:

[dean-yates]

I reproduced the underlying missing authenticated reply-capability failure on Buzz Desktop 0.5.10 with both the built-in Hermes preset and profile-isolated custom Hermes ACP harnesses. The managed agent receives the event and completes the turn, but the generated response remains in Activity because the explicit publish step has no authenticated companion.

I also checked this PR against current main (9e0c6b43). The patch no longer applies cleanly because the managed-agent readiness/spawn-hash code has moved since the PR base, while current main still appears to lack an mcpCommand field on HarnessDefinition and still derives the effective sidecar only from the known-runtime catalog.

I would be happy to help port this focused custom-harness sidecar support to current main and test it against the live 0.5.10 Hermes reproduction. To avoid opening a competing PR, would you prefer:

1. an updated commit/PR based on this implementation, with attribution and current-main regression tests; or
2. test/review evidence posted here while the original author rebases?

The verification I can provide is deliberately credential-free: custom harness round-trip, effective spawn descriptor, restart-hash change, ACP session/new receiving the sidecar, and real DM/channel publication without exposing the managed identity key to Hermes's ordinary terminal.