Fix unTar resolving GNU tar on Windows when extracting .zip dependencies

[cderv]

When quarto-bld extracts a dependency archive on Windows and PATH puts Git's usr/bin ahead of System32 (a common Git for Windows layout), unTar fails with a gzip "unexpected end of file" alongside tar (child): Cannot connect to C: resolve failed.

Root Cause

unTar/makeTarball invoke bare tar via Deno.run, so resolution depends entirely on PATH. Windows ships bsdtar at System32\tar.exe, which reads ZIP archives, but GNU tar from a Git installation cannot read ZIP and additionally misparses a Windows absolute path (C:\...) as a remote-host spec. The compression flag also defaulted to z (gzip) for any extension other than .xz/.bz2, so .zip inputs were extracted with tar -xvzf — only working because bsdtar is lenient about format detection, and masking the real failure once GNU tar is picked up instead.

configure.cmd already solved the PATH half of this for the Deno bootstrap by calling %WINDIR%\System32\tar.exe directly; quarto-bld's dependency extraction (Dart Sass, esbuild, Typst, deno_dom) never got the same treatment.

Fix

Extracts the command-building logic in package/src/util/tar.ts into pure, unit-tested functions: windowsSystemTar builds the System32 path, resolveTarBinary prefers it on Windows when present and falls back to PATH tar otherwise (matching configure.cmd's existing precedent), and tarCompressFlag stops emitting a gzip flag for .zip inputs so bsdtar can detect the format itself. unTar and makeTarball are wired through these helpers instead of hardcoding "tar".

Adding the first test file that imports tar.ts surfaced two pre-existing Deno.run type errors under deno test --check (Deno 2 removed Deno.run from its types but the runtime still implements it). Each call site now carries a @ts-expect-error comment, matching Deno's own documented migration guidance for this API rather than a shared type patch.

Migrating these call sites to Deno.Command is left as separate, unrelated cleanup.

[posit-snyk-bot]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.