ci: bound every job, so a hang fails instead of idling

[mattpodwysocki]

Follow-up to #13, which fixes the test that hung. This stops the next hang costing six hours.

Why

None of the four jobs had a timeout-minutes, so each inherited GitHub's six-hour default. That's what a test blocking on accept() with no deadline cost the Windows leg — and the only reason it went unnoticed for a day is that every run on main during the 0.2.0 merges was cancelled by the next push before it could finish.

Twenty minutes isn't a budget. These legs take one to two minutes; it's a tripwire set about ten times longer than anything here has ever needed.

On all four, not just Windows

installer and installer-windows both stand up local servers in test-install.sh and test-install.ps1, so they can wedge exactly the same way. And a Unix leg that suddenly needs twenty minutes has something wrong with it worth hearing about too.

The reasoning lives once, on build, where it actually happened.

Related, and not fixable in a file

While checking whether this would have helped sooner, I found that neither repo requires any status check. Both are covered only by org-level rulesets — Public Repo - Default Rules here, All Repo CodeOwner Review on the private side — and neither has a required_status_checks rule.

So it isn't that Windows specifically slipped through: nothing gates a merge on CI at all. The pull_request rule requires a review; nothing requires it to be green. That's why #5 merged with Windows unfinished.

I tried to add a repo-level ruleset and got a 404 — I have maintain, not admin. It also can't be fixed by editing the org ruleset, which is shared across every public repo in the org. @mattpodwysocki has the exact gh api call; it wants someone with admin on this repo.

A timeout without required checks still lets a red leg merge, and required checks without a timeout means a hang blocks the queue for six hours. The pair is what actually closes it.

[mattpodwysocki]

Rebased onto #13 and retargeted there, because this would otherwise have gone red for a reason worth explaining.

It was branched from main, which still carries the unbounded accept(). So its own Windows leg was about to hang — but with this change in place, for a pull_request event GitHub uses the workflow from the PR's head, so it would have been killed at 20 minutes instead of six hours. The change demonstrating itself by failing is a decent advertisement, but not a reviewable state.

Now it sits on top of #13, so the hanging test is gone from the branch (incoming().next(): 0 occurrences) and CI should be green on its own merits. GitHub will retarget this to main automatically when #13 merges.

Order that matters, and it is not only about this PR: #13 has to land before required status checks are switched on. main still hangs today, so making Windows required first would block every PR on a six-hour leg — including #13 itself. #13 → #14 → ruleset.