ESP32 deploy spawns bare esptool instead of the build-provisioned esptool #1616

Summary

ESP32 deploy spawns a bare esptool resolved from the caller's PATH, even though the build step provisions a pinned esptool for the same environment. When fbuild is run without a Python venv on PATH, every esptool step of the deploy fails with No such file or directory.

Evidence (fbuild 2.5.30, Linux, ESP32-C6)

Running .venv/bin/fbuild <proj> deploy -e esp32c6 -p /dev/ttyACM1 without activating the venv. The daemon log shows provisioning succeeding:

INFO fbuild_build_esp::esp32::orchestrator::packages::platform: provisioned esptool at ~/.fbuild/prod/cache/toolchains/tasmota-esptool/05265084aeae8498/5.1.0/esptool-linux-amd64/esptool

The deploy then ignores it:

deploy error: failed to spawn ["esptool", "--chip", "esp32c6", "--port", "/dev/ttyACM1", ... "write-flash", ...]: No such file or directory (os error 2)

The same command succeeds once the venv is activated: the pip-installed esptool v5.4.0 is picked up from PATH, not the provisioned 5.1.0.

Cause

Esp32Deployer::find_esptool() (crates/fbuild-deploy/src/esp32/deployer.rs) hard-codes vec!["esptool"]. #1234 forwards the caller's PATH, but nothing hands the deployer the path that the build's esptool resolution already produced (the linker uses it via esp32_linker.rs).

Expected

Deploy uses the same esptool the build provisioned (honoring FBUILD_ESPTOOL_PATH), and falls back to a PATH lookup only when provisioning is unavailable. The deploy then works from a bare shell and runs the same esptool version as the build.