ci: binary-split CITGM source download uses stale repository owner

Summary

The npm 11.20.0 release integration failed in the Node.js 22 and Node.js 23 CITGM jobs before [email protected] could be tested.

Failing workflow

Workflow run: https://github.com/npm/cli/actions/runs/35787155620

Failing jobs:

• Node.js 22: https://github.com/npm/cli/actions/runs/35787155620/job/106973411919
• Node.js 23: https://github.com/npm/cli/actions/runs/35787155620/job/106974673276

Failure

Both jobs attempted to download the source archive from:

https://codeload.github.com/maxogden/binary-split/tar.gz/47044d430f5973380bfd4ef3d179f9d5f3eb54b4

The response was not a gzip archive:

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Process completed with exit code 2.

The referenced commit still exists, but GitHub resolves it under the transferred repository:

https://github.com/max-mapper/binary-split/commit/47044d430f5973380bfd4ef3d179f9d5f3eb54b4

The CITGM source URL still uses the former maxogden owner. The old codeload URL returns non archive content, which is streamed directly into tar by .github/workflows/node-integration.yml:

curl -sSL "${{ matrix.url }}" | tar xz -C "$TARGET_DIR" --strip=1

Expected behavior

The integration matrix should use a working source URL for binary-split, and HTTP download failures should be reported as HTTP errors rather than gzip extraction errors.

Suggested changes

1. Update the binary-split source URL to use the current max-mapper repository owner.
2. Use curl --fail --show-error --location for archive downloads so non successful HTTP responses are not passed to tar.

The download handling is the same underlying workflow weakness discussed in #10016, although the unavailable Node.js nightly archive and this stale GitHub repository URL are separate upstream conditions.