fix(ci-versioning): stop misdiagnosing an empty subject set as a missing step

[sakanni]

What

The subject list is written with Set-Content -Value instead of a pipe, so the file exists whenever the collecting step ran. Both guard messages corrected.

Behaviour is otherwise unchanged: a repository that stages nothing still fails. It now fails with the right diagnosis.

Why

$subject | Set-Content -Path 'subject-assemblies.txt' writes nothing when $subject is empty. An empty pipeline never invokes Set-Content's process block, so the file is not created (measured: Test-Path False for @(), True for two items). The guard downstream then takes its first branch:

Subject assembly list missing. The step that collects this repository's build output did not run, so attribution has no subject set.

The step had run. So had the build. The guard's second branch describes the real state correctly and could never be reached, because the only way to reach it was a file that is never written in that state.

Observed on BHoM/Versioning_Toolkit PR #348, run 33619426914: build_subject conclusion success, Staged before subject build: 110 assembl(ies), Collect subject assemblies executed, and the check reported that it had not.

Root cause of the empty set, for the record

Versioning_Toolkit.sln contains two projects and neither stages into the directory the collector scans:

project	post-build target
BHoMUpgrades	C:\ProgramData\BHoM\Upgrades\BHoMUpgrades\
PostBuild	C:\ProgramData\BHoM\Developer\Versioning

Get-StagedAssemblies.ps1's Get-AssemblyStamp scans C:\ProgramData\BHoM\Assemblies only. So the subject set is correctly empty and always will be for this repository. The old message sent the reader to CI plumbing; the answer was in two .csproj PostBuildEvent entries.

Deliberately not in scope

Two decisions are open and are not settled here:

1. Whether a repository that stages nothing type-bearing should skip rather than fail.
2. Which layer decides, given RunCommand.cs handles an empty subject namespace set by warning and continuing — commenting that "some repos legitimately emit nothing that declares a type, so failing them would be a false block" — while this action escalates the same condition to exit 1.

Both are tracked separately. This PR only makes the failure say something true, which is a prerequisite for deciding either.

Verification

New Pester case writes the subject list unconditionally, so absent and empty stay distinguishable, asserted on the -Value form because the file is text under test rather than an executed script. Verified by mutation: reverting the collect step to the pipe form fails exactly that case and nothing else.

Local ci-versioning-action.Tests.ps1: 10 passed, 0 failed. Full .github/scripts/tests suite: 72 passed, 15 failed, against clean develop's 71 passed, 15 failed. Same 15 either way; they are local Windows PowerShell 5.1 failures in the resolve-dependencies ref-marker tests and do not occur on the pwsh 7 CI runner.

Independent of #16 and touches non-adjacent regions of the same file, so the two can merge in either order.