fix(fleet): workers run the running codewhale binary, not PATH's (#7119)

configured_codewhale_binary() fell back to the bare name "codewhale",
so Fleet runs started from `codewhale fleet run` or `POST
/v1/fleet/runs` resolved the worker on PATH. With a minimal PATH
(launchd/Finder, `env -i`) every worker failed with "starting worker
…: No such file or directory", and with an older codewhale earlier on
PATH the run silently used it.

Without CODEWHALE_FLEET_CODEWHALE_BINARY, a process whose executable
stem is codewhale/codew or codewhale-*/codew-* now uses
std::env::current_exe(). Other hosts (test harnesses such as
codewhale_tui-<hash>) keep the old "codewhale" default, so they never
spawn themselves as workers. Windows codewhale.exe matches the same
stem. Reported and verified by the QA session.

Verified on Boat vm19 (Linux x86_64) at base 804b7fca89 + this change:
`cargo test -p codewhale-tui --lib --locked fleet::` 452 passed, 0
failed. QA ran the built binary (sha256 513820fa…5558e3) under its own
name `codewhale-7119b` against a mock provider: with PATH=/usr/bin:/bin
and no codewhale on PATH, Fleet completed 2/2 (both workers exit 0);
with a stale `codewhale` first on PATH, 2/2 and the stale binary was
never invoked (CW/artifacts/qa-20261027/fleet/vm19-7119b-ownname.txt).
The previous gate (exact stem only) failed both cases under that name.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

CHANGELOG.md

@@ -7,6 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+- **Fleet workers run the same Codewhale:** `codewhale fleet run` and Runtime API Fleet runs (`POST /v1/fleet/runs`) now start workers from the running `codewhale` binary instead of whichever `codewhale` is first on `PATH`, so they work with a minimal `PATH` and never pick up a stale copy. `CODEWHALE_FLEET_CODEWHALE_BINARY` still overrides it. (#7119)
 - **Pinned marketplace archives:** a Codewhale or Claude marketplace entry whose tarball source carries a `sha256` now installs only when the downloaded bytes match it; a mismatch, a malformed pin or a pin on a non-archive source refuses the install with nothing written. The pin also applies to direct installs as `https://…/x.tar.gz#sha256=<hex>`. (E2, CW-6732)
 - **Sandboxed commands cannot plant git hooks or edit git config:** in workspace-write mode, `.git/hooks` and `.git/config` (and a linked worktree's shared `hooks` and `config`) are read-only to sandboxed commands, so a command cannot leave a hook or `core.hooksPath` that later runs outside the sandbox. The workspace's `.codewhale/` is protected even before it exists (on Linux it is created first, because bubblewrap can only protect existing paths). `git commit` and ordinary file writes are unaffected; `git config` writes and hook edits need an approved unsandboxed command.
 - **Interrupted session hint stays visible (#7095):** when a plain `codewhale` launch finds an in-flight session snapshot, the "Run `codewhale --continue` to resume it" hint now appears in the TUI's status line instead of being printed to the terminal just before the TUI covered it.

crates/tui/CHANGELOG.md

@@ -7,6 +7,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+- **Fleet workers run the same Codewhale:** `codewhale fleet run` and Runtime API Fleet runs (`POST /v1/fleet/runs`) now start workers from the running `codewhale` binary instead of whichever `codewhale` is first on `PATH`, so they work with a minimal `PATH` and never pick up a stale copy. `CODEWHALE_FLEET_CODEWHALE_BINARY` still overrides it. (#7119)
 - **Pinned marketplace archives:** a Codewhale or Claude marketplace entry whose tarball source carries a `sha256` now installs only when the downloaded bytes match it; a mismatch, a malformed pin or a pin on a non-archive source refuses the install with nothing written. The pin also applies to direct installs as `https://…/x.tar.gz#sha256=<hex>`. (E2, CW-6732)
 - **Sandboxed commands cannot plant git hooks or edit git config:** in workspace-write mode, `.git/hooks` and `.git/config` (and a linked worktree's shared `hooks` and `config`) are read-only to sandboxed commands, so a command cannot leave a hook or `core.hooksPath` that later runs outside the sandbox. The workspace's `.codewhale/` is protected even before it exists (on Linux it is created first, because bubblewrap can only protect existing paths). `git commit` and ordinary file writes are unaffected; `git config` writes and hook edits need an approved unsandboxed command.
 - **Interrupted session hint stays visible (#7095):** when a plain `codewhale` launch finds an in-flight session snapshot, the "Run `codewhale --continue` to resume it" hint now appears in the TUI's status line instead of being printed to the terminal just before the TUI covered it.

crates/tui/src/fleet/executor.rs

@@ -59,6 +59,14 @@ pub fn configured_codewhale_binary() -> String {
         .ok()
         .map(|value| value.trim().to_string())
         .filter(|value| !value.is_empty())
+        .or_else(|| {
+            let exe = std::env::current_exe().ok()?;
+            let stem = exe.file_stem()?.to_str()?;
+            let cli = matches!(stem, "codewhale" | "codew")
+                || stem.starts_with("codewhale-")
+                || stem.starts_with("codew-");
+            cli.then(|| exe.to_string_lossy().into_owned())
+        })
         .unwrap_or_else(|| "codewhale".to_string())
 }