CI: find a solution for including custom PlatformIO build envs from PRs (usermods) in CI builds

[coderabbitai]

Problem

When a PR introduces a new usermod (or other feature) that requires a custom PlatformIO build environment, there is currently no clean way to include that environment in CI builds for the PR.

• platformio_override.ini is listed in .gitignore and must not be committed to the repository, so it cannot be used to ship a custom build env in a PR.
• The established workaround is to place an example as usermods/<modname>/platformio_override.ini.sample, but .sample files are not picked up by PlatformIO or the CI pipeline.
• Even the VSCode UI workflow does not solve the CI-build side of the problem — a second file would still be needed.

Impact

• New usermods/features that need non-default build environments cannot be fully validated by CI during code review.
• PR authors resort to committing platformio_override.ini directly (as seen in PR Add DALI support - As a light #5645), which clobbers a developer's local override when they pull the branch.

Possible directions

• A dedicated, version-controlled file (e.g., usermods/<modname>/platformio_build_envs.ini) that CI explicitly includes/merges.
• A CI mechanism that discovers and appends *.ini.sample files from changed usermods.
• Documentation of an agreed-upon interim workaround.

References

• Raised during review of PR Add DALI support - As a light #5645: Add DALI support - As a light #5645 (comment)
• Related docs issue: (Doc request) compiling in platformio - selecting build envs via dropdown WLED-Docs#161

/cc @softhack007

[willmmiles]

The issue description here is describing a solution, not a problem. So I understand clearly: is the actual issue that there exist usermods that put constraints on the environment that are illegible to the per-usermod CI, so that we will have to find some way to override the default configuration to test-build them?

I'm very leery of encouraging this broadly -- it's rife for abuse. I especially want to avoid requiring every usermod to have a sample file that merely replicates the documentation on how to add a single usermod. Replicating the documentation like that is a maintenance nightmare.

A bad example (which we should not support!) is a module requiring pin specifications as -D entries in build_flags.

A weak example would be inter-usermod dependencies -- the library resolver won't pick them up. This is arguably more of an internal tooling bug and is best corrected in load_usermods.py.

A mid example would be a module that requires a specific platform -- documented in library.json, but harder to discover in CI.

I'm probably missing something else though?