Desktop: remote-backend agents are gated on the local PATH — readiness probe and provider spawn see different environments

## Summary

For agents created with a remote "Run on" backend (`buzz-backend-*` provider), the desktop evaluates harness availability against the **local machine's login-shell PATH**, while it spawns the provider itself **without** that PATH. Discovery and spawn see different environments, and neither consults the machine the agent will actually run on. Two concrete failures from operating a remote (SSH systemd) backend provider in production:

## Symptom 1: create-mode Save gated on a local binary for a remote agent

`AgentDefinitionDialog`'s create-mode submit requires `selectedRuntime?.availability === "available"`, and availability comes from local prereq discovery (`useManagedAgentPrereqsQuery`) — the remote provider is never asked. To create a "Run on: " agent whose harness (e.g. a custom ACP adapter) exists only on the remote host, you must install the binary locally (or a stub that exits 1) purely to satisfy the probe. The stub workaround works but means the gate is validating the wrong machine.

## Symptom 2: provider shims fail exit-127 depending on how the desktop was launched

The provider subprocess is spawned with the bare GUI environment. A `buzz-backend-*` shim whose first line is `exec bun /path/to/provider.ts` fails:

```
Could not probe provider: provider failed (exit code 127).
stderr: .../buzz-backend-jarvis: line 2: exec: bun: not found
```

…but only when the desktop was launched from Finder/Dock; launched from a terminal it inherits the login PATH and works. Since harness-readiness detection DOES probe the login-shell PATH, the same install can pass discovery and fail spawn. (Workaround: shims must hardcode absolute interpreter paths.)

## Proposed direction

- For remote backends, delegate harness availability to the provider — providers already answer a probe op (`{"op":"info"}`), so an `{"op":"check-harness","command":...}` (or including harness inventory in `info`) would let the dialog gate on the machine that matters, and the local stub workaround disappears.
- Spawn provider subprocesses through the user's login shell (matching how readiness detection resolves binaries), or document that `buzz-backend-*` shims must use absolute paths.

Happy to work on a PR for either piece if maintainers agree on a direction.

Closest existing issues (not duplicates, adjacent provider seams): #3034 (provider-backed agents display local config), #2798 (config saves don't redeploy).