Channel API: legacy FastLED.addLeds<..., fl::Bus B> trailing template parameter

[zackees]

Context

Follow-up to #2459. The runtime miss diagnostic in `Channel::showPixels` already mentions two ways to enroll a driver:

1. `fl::enableDriversfl::Bus::X()` — links only the named driver.
2. `FastLED.enableAllDrivers()` — links every driver on the platform.

A third remediation, which the user explicitly asked for, is to let the legacy `FastLED.addLeds<>` shape also pin a Bus at compile time:

```cpp
FastLED.addLeds<WS2812, 4, GRB, fl::Bus::RMT>(leds, n);
FastLED.addLeds<APA102, 23, 18, RGB, DATA_RATE_MHZ(12), fl::Bus::SPI>(leds, n);
```

When `B = fl::Bus::AUTO` (the default), the existing platform-specific legacy paths run unchanged. When `B != fl::Bus::AUTO`, the body would ODR-use `fl::BusTraits::instancePtr()` (linker keep-alive) and route the LEDs through the named driver.

Why this is a separate PR

`FastLED.h` has 23 `addLeds<>` template variants — clockless, SPI, multi-LED, RGBW, and platform-specific shapes. Adding a trailing default `fl::Bus B` parameter to each mechanically is straightforward, but the body change is not: each variant currently constructs a platform-specific `CLEDController` subclass (e.g. `ClocklessIdf5`, `SPIController`) directly. There are two ways to do the Bus-routing inside:

• Option A — Channel API route: when `B != AUTO`, build a `fl::ChannelConfig` from the chipset/pin/order template args, set `cfg.options.mBus = B`, and call `Channel::create(cfg)` instead of the legacy controller path. Pros: shares the diagnostic + manager dispatch with non-template `FastLED.add`. Cons: needs a chipset → timing-config mapping for every `ESPIChipsets` value.
• Option B — Pre-bind on the legacy controller: keep the legacy CLEDController construction, then call `controller->setDriver(fl::BusTraits::instancePtr())` to pre-bind (using the Phase 5b mechanism). Pros: no Channel API detour, no new chipset → timing mapping. Cons: requires every legacy CLEDController to have a working `setDriver` path, which not all of them do today.

Both options are workable; the choice deserves its own design discussion + review cycle.

Acceptance criteria

• Every `FastLED.addLeds<...>` variant accepts an optional trailing `fl::Bus B = fl::Bus::AUTO` template parameter.
• `B = fl::Bus::AUTO` (the default) leaves existing call sites byte-for-byte unchanged.
• `B != fl::Bus::AUTO` ODR-uses `fl::BusTraits::instancePtr()` so `--gc-sections` keeps only the named driver TU.
• The runtime miss diagnostic in `channel.cpp.hpp` is updated to include the new `addLeds<..., fl::Bus::X>(...)` remediation alongside the existing `enableDrivers` / `enableAllDrivers` options.
• Tests cover at least one clockless and one SPI variant with the new trailing parameter.

Related

• Channel API: collapse to non-template FastLED.add(), Bus-typed affinity, addLeds<..., fl::Bus> trailing parameter #2459 — parent (collapse to non-template `FastLED.add()`, Bus-typed affinity, miss diagnostic). The diagnostic message in Channel API: collapse to non-template FastLED.add(), Bus-typed affinity, addLeds<..., fl::Bus> trailing parameter #2459 deliberately omits the `addLeds<..., Bus>` path until this issue lands.
• feat(channels): compile-time Bus binding via templated ChannelConfig (eliminates Channel API binary bloat) #2428 — grandparent meta-issue.