Problem

vp installs of some preview builds fail in pnpm:

ERR_PNPM_TARBALL_EXTRACT  Failed to add tarball from
".../tarballs/@voidzero-dev/vite-plus-core/0.0.0-commit.14f13284....tgz" to store:
Invalid checksum for TAR header at offset 5038080. Expected 0, got NaN

Root cause

buildPreviewTarball repacks upstream tarballs with nanotar's createTarGzip. nanotar rounds the archive up to a full 10240-byte record and relies on the zero slack to form the mandatory end-of-archive marker (two 512-byte zero blocks). When the packed size is already an exact multiple of 10240, it adds no slack and emits no marker (and only a single block when the size is 512 short of a record).

Lenient readers (BSD/GNU tar, gzip -t) tolerate the omission; pnpm's strict extractor reads a header past EOF and fails with Expected 0, got NaN. @voidzero-dev/vite-plus-core@0.0.0-commit.14f13284 repacks to exactly 5038080 = 492 * 10240 bytes, hitting the boundary.

This is unrelated to #49 (which only touched the download path); reverting it could not have helped.

Fix

Build the raw tar, guarantee the marker (append two zero blocks whenever the last 1024 bytes are not already zero), then gzip. A no-op for normal archives, so every already-correct tarball's bytes and integrity are byte-identical; only boundary cases change. Rebuilt the publish-preview action bundle, which packs via the same buildPreviewTarball.

Test plan

• Added regression test that sweeps packed sizes across a full 10240-byte record (guaranteeing the boundary case) and asserts a valid end-of-archive marker; it fails on main, passes here.
• pnpm typecheck, pnpm test (78/78)
• Verified end-to-end: a marker-less boundary archive built through the fixed code extracts cleanly under strict tar.

Follow-up (post-merge)

The already-corrupted object in R2 for vite-plus-core@0.0.0-commit.14f13284 must be purged/rebuilt so live installs recover; deploying the Worker alone won't rewrite existing bytes.