feat(deploy): wire Teensy dispatch arm so 'fbuild deploy -e teensyXX' actually runs the implemented TeensyDeployer

[zackees]

Problem

```
$ bash autoresearch teensy40 --simd
...
Running: ...\fbuild.exe ... deploy -e teensy40 -p COM22
deploy error: deploy failed: deployer for Teensy not yet implemented
```

But `crates/fbuild-deploy/src/teensy.rs` ships a complete `TeensyDeployer` (171 LOC + unit tests for teensy40 / teensy41 board configs). It just isn't dispatched: `crates/fbuild-daemon/src/handlers/operations/deploy.rs:368` matches on `platform` and only has arms for `Platform::Espressif32`, `AtmelAvr`, `AtmelMegaAvr` — `Platform::Teensy` falls through to the `_ =>` "not yet implemented" return.

This blocks `bash autoresearch teensyXX` (any flag) and `fbuild deploy -e teensyXX` end-to-end from FastLED's side, even though the build succeeds and a `firmware.hex` is produced at `.build\pio\teensyXX.fbuild\build\teensyXX\release\firmware.hex`.

Proposed fix

Add the missing `Platform::Teensy =>` arm in `crates/fbuild-daemon/src/handlers/operations/deploy.rs`. The arm:

1. Loads `BoardConfig::from_board_id(&board_id, ...)` to get the MCU / board name.
2. Constructs `TeensyDeployer::from_board_config(...)` with default `TeensyLoaderParams`.
3. Auto-discovers `teensy_loader_cli` from a sensible search path, in this order:
   • `teensy_loader_cli` (or `.exe`) on `$PATH`
   • `~/.platformio/packages/tool-teensy/teensy_loader_cli` (the path PlatformIO drops it at, available on every PIO-using machine — including the FastLED dev setup)
   • Hard error with a clear message if neither is found, pointing at https://www.pjrc.com/teensy/loader_cli.html for direct install.

No new fbuild dependencies; uses the already-implemented `TeensyDeployer` and its `new(mcu_name, params, loader_path: Option, verbose)` ctor.

Acceptance criteria

• `Platform::Teensy =>` arm exists in `crates/fbuild-daemon/src/handlers/operations/deploy.rs` and routes to `TeensyDeployer`.
• Loader resolution prefers `$PATH`, falls back to `~/.platformio/packages/tool-teensy/teensy_loader_cli`, errors clearly if neither is present.
• `cargo test -p fbuild-deploy` continues to pass (no regression).
• `cargo build -p fbuild-cli --release` succeeds.
• End-to-end: `bash autoresearch teensy40 --simd` on an attached Teensy 4.0 deploys and runs the SIMD RPC suite (verified locally before merge).

Out of scope

• Bundling `teensy_loader_cli` into fbuild's tooling cache (`~/.fbuild/prod/cache/`). That's a longer-running download story and overlaps with how PlatformIO solves it; reusing the PIO-cached binary keeps this PR small and zero-download for any PIO user.
• The deferred soldr-related fbuild dev install (`fbuild#423`) — orthogonal.

References

• `crates/fbuild-deploy/src/teensy.rs` — fully implemented deployer
• `crates/fbuild-daemon/src/handlers/operations/deploy.rs:368` — match arm needing the Teensy case
• feat(simd): add Cortex-M DSP-extension SIMD backend for Teensy 3.x / 4.x (close the SIMD-dispatch gap) FastLED#2628 — the SIMD work that blocked on this