Same concept labeled "Harness" in some surfaces and "Runtime" in others (inconsistent terminology confuses users)

## Describe the problem

The Desktop UI refers to the SAME concept — which agent backend executes the agent (`agent_command`: `buzz-agent`, `goose`, `claude-code`, ...) — by two different names depending on the screen:

| Surface | User-visible label | Source file |
|---|---|---|
| Agent profile (panel) | **Runtime** | `UserProfilePanelFields.tsx` (field `label: "Runtime"`) |
| Agent profile (popover) | badge (no label, raw value) | `UserProfilePopover.tsx` |
| Edit Agent (definition dialog) | **Agent harness** | `AgentHarnessField.tsx` (label "Agent harness") |
| Edit Agent — inherit checkbox | **harness** | `EditAgentAdvancedFields.tsx` ("Inherit harness...") |
| Agents settings section | **Harnesses** | `HarnessesSettingsPanel.tsx` |
| Global Agent Defaults | **harness** | `AgentDefaultsEditor.tsx` ("Select a harness") |
| Agents list row | **Runtime** | `ManagedAgentRow.tsx` (`Runtime`) |

The codebase itself is consistent — it is all "runtime" internally (`runtimeLabel()`, `getDefaultPersonaRuntime()`, `AcpRuntimeCatalogEntry`, `preferred_runtime` in global config; the harness field's own HTML id is `persona-runtime`). "Harness" is only the display wording on edit/settings surfaces. But the user sees "Runtime: buzz-agent" on the profile of an agent whose Edit dialog says "Harness: Goose", with no hint that the two fields are the same axis.

## Why it matters (real confusion, observed)

A user inspecting a built-in agent sees:

- Profile screen: `Runtime: buzz-agent`
- Edit dialog: `Harness: Goose`

and reasonably concludes they are different settings (or that one is stale). They are the same concept: the profile shows the INSTANCE's resolved command, while the edit-definition dialog highlights the global `preferred_runtime` fallback for a persona with no runtime preference. The terminology gap turns an explainable scope difference into an apparent contradiction — users cannot map "harness" ↔ "runtime" without reading the source.

## Suggested directions (not exhaustive)

1. **Pick one term** (e.g. "Runtime") and use it everywhere in user-visible strings, keeping "harness" only where it is a proper noun of the ecosystem (e.g. custom harness registry) — or the reverse.
2. Keep both, but make the mapping explicit in the UI: e.g. the Edit dialog field could read "Runtime (harness)" or the profile tooltip could say "also known as harness".
3. Minimum viable: audit user-visible strings (the table above is a starting inventory) and align at least profile ↔ edit-dialog ↔ agents list row, which are the three surfaces users cross-reference when debugging an agent.

## Environment

- Buzz Desktop v0.5.14 (Windows 11); strings verified against `main` (commit 69107dc) in `desktop/src/features/{profile,agents,settings}`.

Audit the user-visible labels in UserProfilePanelFields.tsx, UserProfilePopover.tsx, AgentHarnessField.tsx, EditAgentAdvancedFields.tsx, HarnessesSettingsPanel.tsx, AgentDefaultsEditor.tsx, and ManagedAgentRow.tsx. Start by comparing the listed surfaces and their existing runtime-related terminology; done means the cross-referenced profile, edit-dialog, settings, defaults, and list labels use a consistent or explicitly mapped term.

Written by the indexing model from the issue text.