ci: keep the release announcement independent of winget, and serialize the bandwidth reloads

[laurentiu021]

Two things, both found while verifying the 1.57.2 release under Protocol C.

1. A failed winget publish suppressed the release announcement

The release published correctly — binary, checksum, SBOM, and a build attestation gh attestation verify accepts. But the winget step failed, and with no continue-on-error, every step after it was skipped:

14 Create GitHub Release: success
15 Sync the winget-pkgs fork with upstream: success
16 Update winget package: failure
17 Post announcement to Discussions: skipped      <-- collateral damage

A release that genuinely shipped was never announced. Those are unrelated concerns: telling users about a published release must not depend on a second distribution channel, in a third-party repository, behind a PAT that can expire.

Fix: winget is now continue-on-error, and a following step turns that into a loud ::warning plus a step summary stating exactly what is and isn't true — the release is on GitHub, it is not on winget, and here are the two things worth checking. Without that second step, continue-on-error would leave one red step inside a green run, which is how something goes unnoticed for weeks.

Winget still runs before the announcement, so when it works the announcement can honestly reference both channels.

Verified by parsing the workflow: 17 steps, continue-on-error: true on winget, order winget(14) → report(15) → announce(16).

2. Two history reloads could rebuild the chart simultaneously

CI threw, from inside LiveCharts:

Operations that change non-concurrent collections must have exclusive access.
  at System.Collections.Generic.HashSet`1.Add
  at LiveChartsCore.Kernel.Observers.CollectionDeepObserver.OnItemsAdded
  at SysManager.Helpers.BulkObservableCollection`1.ReplaceWith
  at SysManager.ViewModels.BandwidthMonitorViewModel.ReloadHistoryAsync

The branch it appeared on changed only a workflow file, so this flake is in main. Main has passed 5/5 recent runs, so it's roughly 1-in-6.

Mechanism: assigning SelectedRange starts a reload fire-and-forget from its changed-handler, and the Refresh button fires the same command — two independent entry points into a method calling ReplaceWith on two collections LiveCharts observes. Its observer maintains a HashSet updated from the change notification; a second caller arriving mid-notification corrupts it. ReloadHistoryAsync now runs behind a SemaphoreSlim, disposed with the VM.

Two earlier diagnoses of this same failure were wrong

Stating this because it's why the commit message quotes the stack trace rather than reasoning:

1. "ReplaceWith lets a Reset subscriber see a half-rebuilt collection" — disproved: notification suppression means the Reset fires after the rebuild. (That investigation did surface two genuine ReplaceWith defects, fixed in fix: align the version with the 1.57.0 tag and add a CI guard so the mismatch cannot recur #1706.)
2. "The poll loop races the reload" — disproved: the failing test never sets IsActive, so the poll loop never samples.

What is NOT proven

That this closes the flake. A harness ran 40 rounds of overlapping reloads against the built assembly, through both entry points, and stayed green with the gate — but also stayed green with the gate disabled. So it does not reproduce the failure and is not a red/green proof. Likely because this machine has 32 cores vs the runner's 4, and because AsyncRelayCommand drops a concurrent invocation rather than running it.

Two regression tests are added at the seam regardless. CI is the only place this fault has ever appeared, so CI is where it has to be judged. If it recurs, the next step is instrumentation, not a fourth guess.

What the gate does provably fix: two reloads can no longer interleave their ReplaceWith calls. That's a real invariant for a UI-bound collection with an external observer, worth holding either way.

Not fixed here

The underlying winget failure. does not have the correct permissions to execute CreateRef is not fork drift (0 commits behind upstream; the in-workflow sync succeeded, so #1687's fix works) and not repo permissions (the account has admin/push on the fork). The same secret published 1.56.8 → 1.56.14, so the PAT has expired or been revoked — that needs a new token, not code. 1.57.2 is on GitHub but not on winget until then.

Both projects build with 0 warnings and 0 errors. Leak scan across all 32 patterns: zero hits.