Since #1663, the test-fixtures-windows CI job checks actual failures against a list of specific tests that are known to fail on Windows when GIX_TEST_IGNORE_ARCHIVES=1. It is therefore capable of providing useful information about new failures, or newly passing tests that should be removed from the list, if the job ever does fail.

The job also seems not to fail. This is to say that while #1358 is not fixed, the test-fixtures-windows job has a very low rate of failure and, if it does fail, something new and interesting would be happening such that we would want to know about it and probably not immediately merge a PR that caused it without checking how and why that happened.

This PR adds test-fixtures-windows to the list of jobs that are dependencies of a required check for branch protection based PR auto-merge.

I know of two possible reasons not to do this now, which should be considered:

• Maybe we don't want PR-blocking job to be able to fail due to an expected failure not failing anymore (though if that happens we would want to take note of it).
• This is one of the longer-running jobs, taking approximately as long as the other Windows test job. Usually they will run in parallel on separate runners, but on occasion when many checks are running on Windows runners in the repository or organization, they might effectively run in series. Maybe we don't want such a long-running job to be a PR-blocking job.

Overall it seems to me that it makes sense to do this (as argued above), but I did want to acknowledge those two counterpoints.