fix(ci-serialisation): report every outcome, and quieten the baseline builds

[sakanni]

Problem

Three defects in ci-serialisation, none of which produces a failure anywhere. Each is a
property of the action as a whole rather than of any one step, which is why none of them was
visible from reading a single place in the file.

A red check can have an empty job summary. The summary was written by five
mutually-exclusive steps, each gated on a different combination of step conclusions and
outputs. Those conditions had to enumerate the states worth reporting, and between them they
named five of the action's eighteen functional steps:

covered:   Compute changed files, Resolve dependencies (branch),
           Build primary repo (branch), Run serialisation tests (branch), Compare
uncovered: the other thirteen

A failure in any of the thirteen matched no condition and wrote nothing, so the check went red
and said nothing at all. Seven of them run before serialisation is attempted — locating and
building the verification solution, inferring its configuration, publishing the runner — which
is exactly the case a reader is least equipped to diagnose, because the natural reading of a red
serialisation check is that serialisation found something.

Two of the four builds annotate the check with the wrong warnings. setup-dotnet registers
the csc problem matcher, which turns every MSBuild diagnostic line into a check-run
annotation. The branch-leg builds pass -clp:ErrorsOnly to suppress that; the two baseline
builds did not. Those two compile the base branch, so their warnings belong to code the
author did not write and cannot act on, and they consume a per-step annotation cap that the
caller's own diagnostics need.

The assemblies directory is reset twice. The base-checkout step removed the contents of
ProgramData\BHoM\Assemblies. The very next step, resolve-dependencies, removes and recreates
that directory and ProgramData\BHoM\Upgrades in its own Prepare folders step, which runs
unconditionally. The earlier line was strictly weaker and strictly redundant — and it is the
line a reader looking for where the two legs are separated finds first.

What changed

One summary step instead of five, always-gated, with the decision extracted to
.github/scripts/Write-SerialisationSummary.ps1 so it can be tested without running a
serialisation check. The five existing messages are unchanged. What is new is the last branch:
a catch-all that names the phase the check stopped in and states that a stop is a CI failure
rather than a finding about the pull request.

The catch-all names the phase, not the step, deliberately. Naming the step would mean giving
all eighteen an id and threading each conclusion into the condition — which is the enumeration
that failed here in the first place. The phase is derived from the signals already available, so
adding a step cannot reopen the hole.

-clp:ErrorsOnly on the two baseline builds. Console output only: no effect on build
behaviour, exit codes, or how errors are reported. Errors still print and still annotate.

The redundant reset removed, with a comment recording where the reset actually happens so
the next reader does not go looking for it here.

Verification

19 new tests, and the three that matter failed before the fix. The first commit adds them
alone; on that commit all three fail, each naming the offending lines rather than describing
them:

[-] writes the summary from a single step that always runs
    Expected 1, but got 5.
[-] passes -clp:ErrorsOnly on every build it runs
    dotnet build "...solution..." --no-restore -c Release --nologo -m
    dotnet build "...ver_sln..." --no-restore -c ... --nologo
[-] leaves the assemblies reset to resolve-dependencies
    Remove-Item "C:\ProgramData\BHoM\Assemblies\*" -Recurse -Force ...

The second commit makes them pass. Sixteen further tests cover the summary decision directly,
including the states that previously produced nothing — a failure before the branch leg ran, a
failure in the baseline leg, and the case where nothing can be identified at all.

Full Pester suite green in CI. The structural tests are text assertions rather than a YAML
parse: the PowerShell test job installs Pester and nothing else, and all three facts are
line-shaped, so a YAML dependency would cost more than it returns.

What is not verified

No end-to-end run exercises the paths this changes. That is a property of the changes, not
a gap in the testing:

• The summary change only alters what is written on paths where the check fails. A passing
  run produces the same summary as before.
• -clp:ErrorsOnly changes console verbosity. Nothing observable in a green run changes.
• The removed reset is duplicated by the following step, so removing it is inert by
  construction — nothing runs between the two lines.

Reaching the baseline leg for real needs a repository that genuinely fails serialisation, which
is not something the available test repositories provide. It would not prove anything additional
here, and I would rather say so than imply coverage this does not have.

What to look at

• The catch-all branch in Write-SerialisationSummary.ps1. It is the point of the change, and
  it is the branch that will be wrong first if the action gains a phase.
• ci-serialisation-action.Tests.ps1 asserts one always-gated summary step. If a second is
  ever added, that test fails — which is intended, and is the guard against the old shape
  returning.
• The two baseline builds, to confirm the flag is the only difference from their branch-leg
  counterparts.

Not in scope

ci-versioning has the same build-flag asymmetry: its caller build passes -clp:ErrorsOnly
and its verification-solution build does not. Left alone here to keep this to one action.

This does not change which checks are required anywhere.