dev lane: managed agents resolve a zero-byte `buzz` sidecar — `just dev` never replaces the Tauri stubs beside the app executable

**Describe the bug**

On a clean `just dev`, every managed agent's `buzz` CLI is unresolvable or zero-byte, so buzz-cli skill commands fail silently — including `buzz agents draft-create` (conversational agent setup). Looks like a trigger behind the symptom family in #2459.

Causal chain (each step verified on disk):

1. `_ensure-sidecar-stubs` touches five zero-byte placeholders in `desktop/src-tauri/binaries/` (the Tauri externalBin compile gate — intentional, per #2492).
2. Tauri dev copies those stubs beside the app executable in `desktop/src-tauri/target/debug/` (arch suffix dropped). The real binaries are built into the WORKSPACE `target/debug/` — `desktop/src-tauri` resolves to its own Cargo target dir, so nothing ever replaces the stubs.
3. `build_augmented_path` (`managed_agents/runtime/path.rs`) puts `~/.local/bin` at entry 1 and exe_parent — the stub directory — at entry 5. A live agent's composed PATH:

```
~/.local/bin <- only `buzz-dev` (see 4)
.../Application Support/Buzz/node-tools/bin
.../Application Support/Buzz/runtimes/node/.../bin
~/Projects/buzz/desktop/src-tauri/target/debug <- five zero-byte stubs
...login shell PATH (no buzz anywhere)
```

`command -v buzz` on that PATH: not resolvable (the stub is mode 644, zero bytes).
4. `ensure_cli_symlink` (`nest.rs:366`) gates on `buzz_bin.exists()` — which passes on the zero-byte stub — and links `~/.local/bin/buzz-dev` to it. Dev builds deliberately link only `buzz-dev`, and agents invoke bare `buzz` (buzz-cli SKILL.md), so the human symlink cannot save the agent lane either.

Net: in the dev lane, the documented agent contract ("agents find the CLI via PATH augmentation", `nest.rs:361-362`) is broken by construction. `desktop-standalone` stages all five binaries; `dev`, `staging`, and `production` recipes do not. `scripts/bundle-sidecars.sh` is release-only (`SRC_DIR="target/release"`), so it cannot serve `just dev` as written.

**Steps to reproduce**

1. `just dev` — wait for desktop + managed agents to come up
2. `ls -la desktop/src-tauri/target/debug/buzz` — 0 bytes, mode 644
3. Ask any managed agent to run `buzz --help` — command not found / silent failure (agent-visible buzz-cli actions like `buzz agents draft-create` fail)

**Expected behavior**

A managed agent spawned by the dev-lane desktop can resolve and execute a real `buzz` CLI via its augmented PATH, per the contract in `nest.rs`.

**Version and platform**

- Buzz version: v0.5.2 (also confirmed on v0.5.0/v0.5.1; relevant recipes/code unchanged on current main by inspection)
- OS: macOS 15 (Darwin 24.6.0, Apple Silicon)

**Logs / additional context**

Duplicate search: closest are #2492 (Windows stub suffix — documents the stubs as intentional compile gates, different failure) and #2459 (lost agent replies when the agent's buzz CLI write fails — unconfirmed trigger, consistent with this). Open PRs #2655 / #3069 touch bundled/packaged sidecar preference for releases; neither appears to close the dev-lane staging gap.

Questions before we write any code:

1. Do #2655 / #3069 already own this, or is the dev-lane staging gap separate?
2. What is the intended dev-lane contract: should `just dev` stage debug sidecars into the exe-parent dir, or are dev agents expected to obtain `buzz` another way?
3. Should `ensure_cli_symlink`'s `.exists()` gate test executability/non-zero size so it never links to a stub?

Happy to PR the minimal fix for whichever contract you confirm. Our local workaround (post-`just dev` staging of the five workspace-target binaries into the exe-parent dir, fail-closed) restores agents immediately, so no urgency on our side.