[3.0][Testing] Run the unit tests on Windows as well as Linux

[albertlast]

Description

#9595 asked whether the unit tests should run on Windows in CI. This does that.

The suite needs no database, no server and no Docker — it is PHPUnit against Sources/ with the constants tests/bootstrap.php defines — so the only cost of a second operating system in the matrix is runner time. What it buys is coverage of the one place the two platforms genuinely differ: path handling, directory separators and line endings. Nothing else in CI looks at those, and #9595 is what that gap looks like in practice.

Two changes:

• os: [ ubuntu-latest, windows-latest ] in the matrix, with runs-on: ${{ matrix.os }}. The Composer cache key already begins with ${{ runner.os }}, so the two platforms keep separate caches and the Windows one gets its own .bat proxies.
• The tests are started with composer test rather than vendor/bin/phpunit. The default shell on a Windows runner is PowerShell, which cannot execute the extensionless Composer proxy; going through Composer resolves to the right binary on either platform, and it is the command AGENTS.md already tells contributors to run. --colors=always is forwarded to PHPUnit unchanged.

.gitattributes forces eol=lf, so a Windows checkout gets the same bytes as a Linux one and nothing here depends on that being true.

This needs #9600 first. SapiTest::testCanonicalPathResolvesDotSegments() fails on Windows on release-3.0 today, which is the bug #9595 reports, so the two new jobs here will be red until that one is merged.

Issues References (Fixes|Related|Closes)

1. Related to SapiTest fails on Windows #9595
2. Depends on [3.0][Testing] Anchor the canonical path test to the root the platform actually uses #9600

[albertlast]

The two new jobs here are red, and it is the failure #9595 reports rather than anything about the matrix. Both Windows runs got through all 169 tests with only SapiTest::testCanonicalPathResolvesDotSegments() failing, so composer test under PowerShell, the separate Composer cache and the checkout are all working:

1) SMF\Tests\Unit\SapiTest::testCanonicalPathResolvesDotSegments
Failed asserting that two strings are identical.
-'/a/c'
+'D:\a\c'

D: rather than C: is the runner's drive, which is the same point #9600 is about: the old assertion depended on where the checkout happened to sit.

I ran the two branches together on a throwaway pull request in my own fork to confirm nothing else is waiting behind it, and all four jobs pass — ubuntu 8.4, ubuntu 8.5, windows 8.4, windows 8.5. So merging #9600 first turns this one green with no further changes.

[jdarwood007]

Rebase this PR and they should pass.

[live627]

not yet; I think the test might be too brittle.

[albertlast]

Green on all four jobs now — ubuntu and windows, 8.4 and 8.5.

Rebasing onto a release-3.0 that has #9600 in it cleared the original failure, but Windows then died somewhere else entirely, and it is worth writing down because it is exactly the kind of thing this job is for:

Error: loop detected. The database may have failed or crashed.
Fatal error: Premature end of PHP process when running
SMF\Tests\Unit\AvatarTest::testAGalleryAvatarInTheRootOfTheGalleryIsFoundToo

The runner's PHP has no fileinfo extension on Windows, where it does on Linux. Utils::getMimeType() logs required_extension_missing when it is absent, Avatar calls it for every gallery avatar it resolves, and the third logged error in a process trips the loop guard in ErrorHandlerService::log(), which var_dump()s a backtrace and die()s — taking PHPUnit's worker with it.

So the second commit names the extensions in the setup-php step rather than taking whatever the runner happens to ship. fileinfo and mbstring are not optional for SMF: Maintenance\Tools\Install refuses to install without either, and .docker/README.md lists both as required. Asking for them makes the job assume no more than the code already does, and it applies to both platforms.

Worth noting separately that the loop guard is doing something surprising here. $error_call is a static that only ever increments, so it is not counting recursion, it is counting every error logged in the process — the third unrelated one dies with a raw var_dump. I will open an issue for that rather than widen this pull request.