docs: revert speculative vitest pool fix, document as open runner-level issue

The forks-pool change didn't fix it (failure went from 1s to 0s, if
anything worse) -- reverting to plain 'npm test' since it's no more or
less broken and is simpler. Documenting this as a known open item needing
someone with actual authenticated Gitea dashboard access, rather than
continuing to guess blindly from outside.

.github/workflows/build-verify.yml

@@ -79,14 +79,19 @@ jobs:
           exit $MISSING
 
       - name: vitest
-        run: npx vitest run --pool=forks --poolOptions.forks.minForks=1 --poolOptions.forks.maxForks=2 --reporter=verbose
+        run: npm test
-        # 2026-07-16: `npm test` (plain `vitest run`, default thread pool) fails in
+        # KNOWN OPEN ISSUE (2026-07-16): this step fails in 0-1s on this specific
-        # ~1s on this runner with no visible cause -- passes reliably every way
+        # Gitea Actions runner for a reason not diagnosable from a local machine --
-        # tried locally (plain, CI=true, and a fully fresh `rm -rf node_modules &&
+        # tried forcing a small fixed forks pool (--pool=forks, min/maxForks) as a
-        # npm ci`, all 215/215). A 1s failure with no per-test output strongly
+        # guess (common fix for CI-only vitest worker-pool crashes), made no
-        # suggests a worker-pool crash specific to this runner's environment, not
+        # difference. The actual test suite passes 215/215 reliably every way
-        # a real test regression. Forcing the forks pool with a small, fixed
+        # tested locally: plain `npm test`, with CI=true set, and after a fully
-        # worker count is a common fix for that class of CI-only vitest failure.
+        # fresh `rm -rf node_modules && npm ci`. The job's "Complete job" step
-        # If this step is STILL red after this change, the failure is a runner
+        # also shows failure/canRerun:false, which may indicate a runner-level
-        # environment issue outside what can be diagnosed from a local machine --
+        # issue rather than a test-code issue. Needs someone with actual
-        # needs someone with actual dashboard/log access to this Gitea instance.
+        # logged-in dashboard access to this Gitea instance to read the real
+        # step log -- not accessible via this session's tooling (Gitea Actions
+        # log API returned 404 for every endpoint pattern tried; the web log
+        # viewer requires an authenticated session to stream content).
+        # Every OTHER step in this workflow (syntax, require() check, typecheck,
+        # build) is confirmed working and already caught 2 real bugs today.