perf(deploy): replace esptool subprocess with espflash native crate

[zackees]

Split out from #18 item 5.

Problem

verify-flash and write-flash currently shell out to Python esptool. Cost breakdown for verifying a 2.4 MB ESP32-S3 image (~5.9 s total):

Phase	Estimated cost
Python interpreter startup	~1 s
Subprocess spawn + esptool init	~0.5 s
Connect + reset chip into bootloader	~1 s
SYNC handshake + stub flasher upload	~1 s
Baud rate change	~0.5 s
FLASH_MD5SUM execution (3 regions, 2.4 MB)	~1 s
Cleanup + reset back to app	~0.5 s

Actual MD5 work is ~1 s; the rest is process/Python overhead.

Proposed fix

Use the espflash crate — Rust-native ESP32 flasher protocol maintained by ESP-RS. Exposes SLIP protocol, stub flasher loading, and FLASH_MD5SUM natively.

espflash = { version = "4", default-features = false, features = ["serialport"] }

Reuse the daemon's existing serial port lease instead of spawning a subprocess.

Estimated win

• First verify in a session: ~5.9 s → ~1.5–2 s
• Subsequent verifies reusing the loaded stub flasher: <1 s

Effort

Medium. The espflash library API is less stable than the CLI — may need an adapter layer between fbuild's Esp32Deployer and espflash's Flasher type. Worth a spike to confirm feasibility before committing.

Context

Filed during the issue consolidation that closed tracker #18. See #18 for the original framing.

[zackees]

Progress update — verify-flash migrated:

• PR spike(deploy): add espflash crate + feasibility module (partial #66) #74 (spike) — added espflash = 4 with default-features = false, features = ["serialport"] and a compile-only esp32_native module documenting what a real migration needs.
• PR perf(deploy): use espflash crate for verify-flash (partial #66) #89 — verify-flash via espflash::Flasher behind FBUILD_USE_ESPFLASH_VERIFY=1 (default still esptool subprocess for safety). Native verify reuses the serial port through SharedSerialManager::preempt_for_deploy, computes MD5 against flasher.checksum_md5(offset, len), hard-resets on Match. Saves the ~1s Python interpreter startup + ~0.5s subprocess spawn per verify.

Remaining: write-flash migration. Deferred from PR #89 for two reasons: (1) needs a progress-callback bridge to the daemon's WebSocket log stream so users see upload progress, (2) stricter error recovery for partial writes / USB re-enumeration. Picking that up next.