drv/rgbled: disconnect SPIM SCK to free mcu-led3 on DotBot v3 bd1.3+

[geonnave]

Problem

db_rgbled_init() claims P1.06 as the SPIM SCK output for the TLC5973D one-wire driver. On DotBot v3 board build 1.3+ (per bd1.3a changelog: "added 2 more LEDs on the MCU"), P1.06 is wired to mcu-led3 (D24). Because SPIM SCK idles HIGH, that LED stays permanently lit any time the driver is initialized.

Fix

SCK is not electrically required by the TLC5973D protocol (it's a one-wire driver — only the MOSI pulse widths carry data; SPIM's internal serializer still runs fine without an exposed SCK pin). Configure PSEL.SCK as Disconnected and drop the _sck_pin constant + its db_gpio_init call.

Cross-board safety

Verified against the DotBots/DotBot-hardware tag history:

• DotBot v2 (tags v1.4-v1.8.2, nRF52840 era): P1.06 has no consumer in the schematic. Old driver was harmless there; new driver is identical.
• DotBot v3 ≤ bd1.2 (tags v2.0.0-v2.1.0, nRF5340 era pre-LED3): same — P1.06 exists as a global net label but no LED/peripheral wired to it.
• DotBot v3 ≥ bd1.3: P1.06 is mcu-led3. This is the case the fix targets.

So the change is strictly safer on every revision.

Validated

• Builds clean under gcc-arm-none-eabi 15.2.1 with clang-format --dry-run --Werror.
• Compiled into the proto firmware sandbox app, flashed on a real DotBot v3 board (S/N 774594398), and confirmed visually that mcu-led3 no longer lights up while the blue RGB heartbeat continues to blink normally.

Plus inline comments in rgbled.c: a paragraph in the file header explaining the WS2812-style SPIM-MOSI-as-NRZ-pulse-generator trick (since the technique surprises every first reader), and a short comment at the PSEL.SCK line explaining why disconnecting is safe.