ci: retry npm registry reads before failing a check

The frozen-manifest job read ETIMEDOUT from the registry installing the client
deps, after it had already cloned core at the pin and proved core's own manifest
regenerates — a red X that meant nothing about this PR. There are five `npm ci`
calls across the three jobs and the runner is shared, so this will recur.

npm's own retry, turned up at the workflow level so every install gets it.

Co-Authored-By: Claude <noreply@anthropic.com>

.gitea/workflows/pr-checks.yml

@@ -73,6 +73,15 @@ concurrency:
   group: pr-checks-${{ github.ref }}
   cancel-in-progress: true
 
+# npm's own retry, turned up. The shared runner reads ETIMEDOUT from the registry
+# often enough to matter, and there are five `npm ci` calls across these jobs — a
+# red X that means "the network hiccuped" costs a reviewer more than it costs the
+# runner to retry, and teaches everyone to re-run rather than read a failure.
+env:
+  NPM_CONFIG_FETCH_RETRIES: 5
+  NPM_CONFIG_FETCH_RETRY_MINTIMEOUT: 20000
+  NPM_CONFIG_FETCH_RETRY_MAXTIMEOUT: 120000
+
 jobs:
   server-tests:
     runs-on: ubuntu-latest