Fixed incremental multi-component changes in CI

[Arlodotexe]

Background

Our CI occasionally failed when passing changed components into tooling/MultiTarget/Filter-Supported-Components.ps1. We traced it to the producer script tooling/Get-Changed-Components.ps1, which historically returned a single comma-separated string list of component names rather than discrete items.

Commit history investigation for Get-Changed-Components.ps1 in the tooling repo:

• 62d37e0 (2025-04-06): initial behavior assembled a comma-separated string list (with quoting at the time) and returned it as a single value.
• 1d93ddf (2025-06-09): removed quoting but still returned a comma-separated string list.
• Current change: return discrete items instead of a comma-separated string list so callers binding to [string[]] receive proper arrays.

Problem

7s
Run $changedComponents = $(./tooling/Get-Changed-Components.ps1 a4763705deb76c7815404ecd390599522236f2ea 39e46f5197e13c25227af645d63f3098186d270a)
From https://github.com/CommunityToolkit/Labs-Windows
 * branch              a4763705deb76c7815404ecd390599522236f2ea -> FETCH_HEAD
From https://github.com/CommunityToolkit/Labs-Windows
 * branch              main       -> FETCH_HEAD
Get-ChildItem: D:\a\Labs-Windows\Labs-Windows\tooling\MultiTarget\Filter-Supported-Components.ps1:48
Line |
  48 |      foreach ($componentCsproj in Get-ChildItem -Path $path) {
     |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot find path 'D:\a\Labs-Windows\Labs-Windows\components\OpacityMaskView,Ribbon\src' because it does not
     | exist.
Error: Process completed with exit code 1.

Filter-Supported-Components.ps1 received a single string value like OpacityMaskView,Ribbon instead of a string[]; it then treated that comma-separated string list as a literal path segment, causing the missing path error.

Solution

• Change Get-Changed-Components.ps1 to return discrete items directly (one item per component name) rather than a comma-separated string list.
  • Single component → returns a single string; PowerShell binds it to [string[]] as one element.
  • Multiple components → returns multiple items; callers receive a proper array.
  • Non-component or mixed changes → returns all (unchanged behavior).
• Keep workflow call sites simple: pass the script output directly to -Components without splitting or coercion.
• Validation: tested against a multi-component-only commit; output type System.Object[], length 2, with expected component names; single-component case binds correctly; no changes to Filter-Supported-Components.ps1 and no error masking.