Create-agent harness dropdown shows every option unavailable when CLI is only on login-shell PATH, not GUI PATH

## Summary

Buzz Desktop's manual "Add agent > Create agent" form shows every preset harness (Claude Code, Codex, Buzz Agent, Goose, Amp, Cursor, Devin) as unavailable — even when the corresponding CLI is installed and already in active use by other managed agents on the same machine.

## Reproduction

1. Install `claude`/`codex`/etc. CLIs to a directory that is only added to `PATH` via a login-shell rc file (e.g. `~/.zshrc: export PATH="$HOME/.local/bin:$PATH"`), not present in the OS/launchd default PATH.
2. Launch Buzz Desktop normally (Dock/Finder/LaunchServices — not from a terminal that already has the augmented PATH).
3. Open "Add agent > Create agent" and look at the "Agent harness" dropdown.
4. Every harness option is marked unavailable/CLI-missing, including ones that are demonstrably installed and working.

## Environment

- Buzz Desktop 0.5.18, macOS 26.6.2 (25G83), arm64
- `claude` and `codex` both resolve fine from an interactive shell (`~/.local/bin`), and both are actively running as managed-agent worker pools on this same machine at the time of the repro — so the binaries are not actually missing.
- `launchctl getenv PATH` returns empty on this machine, i.e. a GUI-launched process gets the OS's bare minimum default PATH, not the login-shell PATH that adds `~/.local/bin`.

## Root cause (best guess, unconfirmed against source)

Same class of bug as #4628: Desktop's harness-availability check for the **create-agent UI** appears to run against Electron's bare launchd environment rather than a login-shell-resolved PATH (or a PATH augmented the way the already-working agent-worker spawn path is). That worker-spawn path clearly *can* find these binaries — agents configured via `agent_command_override` (e.g. pointing at a wrapper script under `~/.local/bin`-adjacent paths) start and run fine. Only the **create-agent form's dropdown detection** appears to miss them.

Unlike #4628 (which is a runtime setup-payload parse failure after an agent is already configured with a custom command), this blocks agent creation entirely at the picker stage — before any config is saved — for every preset harness, not just custom ones. Filing separately since the user-facing surface and failure point differ, but flagging as likely related/same-root-cause.

## Impact

Blocks creating any new managed agent through the manual "Create agent" flow, and equally blocks `buzz agents draft-create` (owner-reviewed draft flow) — that command opens the same prefilled create-agent form, so the draft path does not route around the broken dropdown either. On a machine where CLIs are installed via a login-shell PATH addition (a very common setup, e.g. `pipx`, `nvm`, `~/.local/bin` installs), this makes the "Create agent" UI unusable regardless of whether the harness is actually present.

## Suggested fix

Have the create-agent harness-detection check resolve commands the same way the already-working managed-agent spawn path does (inherit/resolve login-shell PATH, or explicitly search common user-local bin dirs like `~/.local/bin`) instead of relying on Electron's bare launchd PATH.

Start at the create-agent form's harness-availability check and compare it with the managed-agent spawn path that already finds configured binaries. Reproduce from a GUI-launched macOS process with a CLI available only through ~/.zshrc, then verify that the preset dropdown and buzz agents draft-create no longer mark installed harnesses unavailable.

Written by the indexing model from the issue text.