Intermittent IOException from GitVersion.MsBuild during parallel project builds ("Build Windows installers" job)

The "Build Windows installers" job intermittently fails at the dotnet pack (and potentially dotnet build) step with:

GitVersion.MsBuild.targets(13,9): error : IOException: The process cannot access the file
'...\_runner_file_commands\set_env_<guid>' because it is being used by another process.

Example: run 30094840174, attempt 1, job "Build Windows installers", step "Pack" — 2026-07-24T14:13:30Z. This forced a re-run, which in turn caused duplicate artifacts and broke the Test Results workflow (#390).

Root cause (high confidence, not yet reproduced in isolation):

Nine .csproj files in this repo each independently reference GitVersion.MsBuild 5.10.3:
Chorus, Chorus.Tests, ChorusHub, ChorusHubApp, ChorusHubTests, ChorusMerge, ChorusMerge.Tests, LibChorus, LibChorus.TestUtilities, LibChorus.Tests, SampleApp, Tests-ChorusPlugin.

dotnet build/dotnet pack (run at the repo root, operating on Chorus.sln) builds these projects with MSBuild's default parallel node execution. Each project's GitVersion.MsBuild task invokes GitHubActions.WriteIntegration, which appends to the file pointed to by $GITHUB_ENV — a single file shared by the whole job, not per-project. When two of these concurrent MSBuild nodes try to open that file at the same instant, one throws the IOException seen above.

This is the same underlying defect reported upstream in GitTools/GitVersion#3737 (Jenkins analog — GitVersion's build-log/env-writing code racing under concurrent invocation), just triggered here via GitHub Actions' GITHUB_ENV file instead of Jenkins' properties file.

Suggested fixes (roughly in order of effort):

1. Force serialized MSBuild execution for the build/pack steps in the "Build Windows installers" job (-maxCpuCount:1 / -m:1) as a low-risk mitigation — trades some build parallelism for eliminating the race outright.
2. Centralize GitVersion invocation (e.g., run dotnet-gitversion once via the CLI and pass the computed version in as MSBuild properties) instead of each of the 12 projects independently invoking the GitVersion.MsBuild task — removes the concurrent-writer problem at the source, but is a bigger refactor.
3. Upgrade GitVersion.MsBuild to 6.x alongside #363 and check whether the race reproduces — worth doing regardless of staleness, but shouldn't be assumed to fix this without verification.

Drafted by Claude Sonnet 5 (claude-sonnet-5).

Start by inspecting the "Build Windows installers" workflow, its build and pack commands, and the listed .csproj files referencing GitVersion.MsBuild 5.10.3. Reproduce the failure around dotnet pack/build, then compare parallel and serialized execution. Done means the job no longer hits the GITHUB_ENV IOException during concurrent builds and reruns do not create duplicate artifacts.