Non-blocking Windows harness still reports `failure` into the PR status rollup, so healthy PRs read as red

[grigolatoe]

Thanks for ringer — I use it via a wrapper skill and read the PR queue fairly often, which is how I ran into this.

Symptom. 10 of the 48 open PRs currently show a failing check. For 9 of them the only failing entry is windows harness (non-blocking), and the workflow run those PRs belong to concluded success.

Why it happens. continue-on-error: true is already set on the windows job in .github/workflows/tests.yml, and it does what it promises at the run level — the run stays green. What it does not do is change the job's own conclusion, and the PR status rollup reads job conclusions. So the run is green and the check is red at the same time.

Concretely, on PR #61:

workflow run conclusion	success
full suite (macos-latest)	success
full suite (ubuntu-latest)	success
windows harness (non-blocking)	failure
what the PR page shows	"Some checks were not successful"

Blast radius. #27, #52, #54, #56, #57, #59, #60, #61 and #62 show red on this alone. (#58 and #62 also fail full suite (macos-latest), which looks like a genuine signal and is not what this issue is about.) The practical cost is that "does this PR pass CI" stops being answerable at a glance across the queue, and a real failure is easy to miss in a list where most of the red is noise.

Possible fixes, in the order I would think about them — though which trade-off is right is your call, not mine:

1. Let the step absorb its own failure so the job concludes success, keeping the log as the artefact:

   - name: Attempt test suite
     continue-on-error: true      # on the STEP, not just the job
     run: python -m unittest discover -s tests -v

2. Keep the job failing but stop it reporting as a check — e.g. move it to a scheduled workflow rather than pull_request, so Windows evidence still accrues without colouring PRs.
3. Leave it exactly as is and treat the red as known noise. That is a legitimate choice; it just seems worth it being a decision rather than a surprise, since the job name already says "non-blocking" and readers reasonably expect that to mean what it says.

Happy to open a PR for (1) if it would be useful — though I have read access only, so it would come from a fork.