esptool: provisioning failure degrades silently to PATH, and there is no FBUILD_ESPTOOL_PATH override

[zackees]

Split out of #1217 so these survive PR #1218 closing it. #1218 fixes the version parse so provisioning succeeds; these two make the failure path survivable when it doesn't.

1. Provisioning failure degrades silently to a PATH lookup

resolve_esptool() (crates/fbuild-build-esp/src/esp32/orchestrator/packages.rs:139-175) logs a tracing::warn! and returns None, and the linker then pushes a bare "esptool" (crates/fbuild-build-esp/src/esp32/esp32_linker.rs:73).

The consequences of that design showed up in #1217:

• The real fault (a 404 on .../download/vunknown/esptool-linux-amd64.zip) was invisible at default verbosity.
• The build ran ~3 more minutes before dying at elf2image.
• The error it finally printed — "esptool not found — Install with: pip install esptool" — was actively misleading. esptool 5.1.0 was installed; it just wasn't on the daemon's PATH.

The module doc has claimed since #954 that this module exists "so no user pip install is required", yet the failure message tells the user to run exactly that.

Ask: when provisioning fails, say so at the point of failure, naming the URL that was tried and the parsed version. If the PATH fallback is retained, make the eventual error state that provisioning was attempted and failed — don't present it as a bare missing-tool error.

2. esptool is the only provisioned tool with no FBUILD_*_PATH override

Every comparable tool has one:

FBUILD_DFU_UTIL_PATH
FBUILD_LPC21ISP_PATH
FBUILD_PROBE_RS_PATH
FBUILD_QEMU_RISCV32_PATH
FBUILD_QEMU_XTENSA_PATH
FBUILD_WCHISP_PATH
FBUILD_WLINK_PATH

esptool has none. That matters more than it looks, because FBUILD_* is the only prefix that survives the daemon's env_clear (crates/fbuild-cli/src/daemon_client.rs:1045-1049) — so it is the only escape hatch that reliably reaches the daemon. During the #1217 outage there was no supported way to point fbuild at a known-good esptool; the workarounds available to a downstream user were all things that mask the bug (a pip install step, symlinking into /usr/local/bin, or pinning fbuild backwards).

Ask: add FBUILD_ESPTOOL_PATH, consistent with the seven above.

Relationship to the other issues

• regression (2.5.4): ESP32 elf2image dies on bare esptool — version parser never resolves pioarduino URL, and the PATH fallback it relies on broke #1217 / PR fix(esptool): parse version from release tag when filename is generic (#1217) #1218 — the version parse. Fixes the immediate outage.
• daemon binds tool resolution to spawn-time PATH for up to 12h — bare-name esptool/python/objcopy spawns resolve nondeterministically #1219 — the daemon binds tool resolution to spawn-time PATH for up to 12h. That's why the fallback failed rather than merely being slow.
• This issue — makes the esptool path debuggable and overridable when provisioning fails for some future reason.

Each is independently useful; none subsumes the others.