Give the v4 workflow its own file name (#2990)

Renaming the workflow in #2989 was not enough. A workflow is identified by its
file path, and the name comes from the copy on the default branch, so this file
was still labelled "CI" because main has a ci.yml. test-report.yml on main runs
after every workflow named "CI", and it failed on every v4 run, Pester 4 writes
NUnit 2.5 XML that dorny/test-reporter cannot read.

ci.yml becomes ci-v4.yml, which makes it a separate workflow with its own name.
The gate job is still "Done".

🤖

Author: nohwnd

.github/workflows/ci.yml .github/workflows/ci-v4.yml.github/workflows/ci.yml renamed to .github/workflows/ci-v4.yml

@@ -5,11 +5,14 @@
 # releasable: green CI here means a security fix can be validated and shipped
 # through the manual release process (release.ps1).
 #
-# The name differs from the workflow on main and on rel/5.x.x on purpose.
+# The file name and the workflow name differ from main and rel/5.x.x on purpose.
 # test-report.yml on main runs after every workflow named "CI" and renders its
 # results, and Pester 4 can only write NUnit 2.5 XML, which dorny/test-reporter
-# cannot read. The gate job below is still called "Done", same as everywhere
-# else, that is the name branch protection requires.
+# cannot read. A workflow is identified by its file path, and its name comes
+# from the copy on the default branch, so while this file was also called
+# ci.yml the rename alone did nothing and the report kept running and failing.
+# The gate job below is still called "Done", same as everywhere else, that is
+# the name branch protection requires.
 name: CI (v4)
 
 on: