Improve custom bus config UI capabilities

[timle2]

Draft / Testing Status

This PR is intentionally draft. It is a proof of concept on top of wled#5704 (WLEDpixelBus_PR) to show how the tested Govee S14 RGB+WW paired-pixel mapping can be represented by the new custom bus driver.

This exact PR 5704-based firmware has not yet been tested on the physical Govee S14 controller. The bulb mapping itself was validated on the earlier dedicated paired-bus prototype in wled#5803; this branch translates that mapping into PR 5704's generic custom-channel model for review.

Why This Change

Some newer string-light bulbs are a single logical lamp but are wired as multiple WS281x-compatible physical pixels. The tested Govee S14 RGB+WW string is one of these: each bulb has one RGB chip and one warm-white chip. For WLED behavior to feel native, effects, segments, presets, JSON API, and Home Assistant should see one logical RGBW bulb, while the driver emits both physical pixels.

PR 5704's custom bus model can represent this without adding a dedicated Govee/S14 LED type. The missing pieces are making the rest of WLED treat the custom channel map as the source of truth for bus capabilities, UI visibility, auto-white behavior, and current estimation.

Concretely, a config can say:

logical RGB controls -> physical wire channels 1,2,3
logical W control    -> physical wire channels 4,5,6

Or for a future bulb with the order reversed:

logical W control    -> physical wire channels 1,2,3
logical RGB controls -> physical wire channels 4,5,6

Both should be represented by changing only cmap; the UI and runtime should then reflect the resulting capabilities.

Summary

This is an incremental patch on top of wled#5704. It keeps paired RGB+WW strings in the generic custom bus path instead of adding a dedicated S14 LED type.

• restore custom bus fields (cch, cmap, timing, inversion) into the LED settings UI from config/import
• make UI white/auto-white visibility follow effective bus capabilities from the custom channel map
• preserve auto-white mode for custom maps that expose W/WW/CW channels
• make current estimation count mapped custom channels, including duplicated W channels

What Changed

LED Settings UI

When custom bus config is enabled (cch > 0), the LED settings page now restores cch, cmap, timing, 16-bit, and inversion fields from saved config or config-template import before deciding what controls to show.

The UI then computes effective capabilities from those config-backed form fields:

• R/G/B entries expose RGB-capable behavior
• W/WW/CW entries expose white controls, including the white slider / RGBW handling and auto-white controls
• both WW and CW expose CCT capability

For the S14 proof-of-concept config, cmap: [3, 1, 2, 4, 4, 4] contains W, so the white / auto-white controls become visible without a dedicated S14 mode.

Bus Runtime

The bus constructor already derives RGB/W/CCT support from the custom map. This patch preserves the configured auto-white mode after that custom capability pass, so a base RGB bus with a custom map containing W can still behave as a logical RGBW bus.

Current Estimation

Current estimation now counts the configured custom channel sources instead of assuming a fixed RGB/RGBW channel count. This matters for paired bulbs where logical W may be duplicated onto three physical wire channels (W,W,W).

Example Mapping

For the Govee S14 RGB+WW paired WS281x string tested with the dedicated prototype:

{
  "type": 22,
  "len": 30,
  "pin": [16],
  "rev": true,
  "rgbwm": 2,
  "drv": 0,
  "cch": 6,
  "cmap": [3, 1, 2, 4, 4, 4]
}

The generic behavior is that cmap maps each physical wire channel to the logical UI source it consumes. In this example, the first three wire channels consume logical B,R,G, and the last three consume logical W. Because the config contains W, WLED treats the bus as having white capability and the LED settings UI exposes white / auto-white controls.

Equivalent future bulbs with different physical ordering should work by changing only cmap, for example W,W,W,B,R,G as [4, 4, 4, 3, 1, 2]. A dual-RGB bulb that mirrors two RGB chips could use a duplicated RGB map such as [3, 1, 2, 3, 1, 2], and white controls would remain hidden because the map has no white source.

Validation

• npm run build
• ../WLED/.venv/bin/pio run -e esp32dev
• npm test
• git diff --check

Firmware artifact: build_output/release/WLED_17.0.0-devV5_ESP32.bin
SHA-256: 638bf8d2e343eea272a4c06efecbcdd585b273ae18263285ab95b65e14a0d5e6

Notes

This PR is intentionally opened against the PR 5704 base branch in this fork to keep the review diff small. It should not be merged independently of PR 5704.