fix(artifact): emit valid range headers

[iamjr15]

Why

Production QA of the new R2 transport found that a valid Range: bytes=0-15 request returned the correct 16 bytes and HTTP 206, but emitted Content-Range: bytes NaN-NaN/<size>.

Cloudflare's R2 runtime range object can expose the suffix property with an undefined value. Property-presence narrowing therefore selected the suffix branch even for offset/length requests.

What changed

• Treat suffix as active only when it is numeric.
• Independently validate numeric offset and length values before normalizing the returned range.
• Preserve the existing bounded range and private/no-store behavior.

No database, API contract, or deployment-topology changes.

Verification

• pnpm --filter @cheatcode/artifact-worker lint
• pnpm --filter @cheatcode/artifact-worker typecheck
• pnpm --filter @cheatcode/artifact-worker build
• pnpm lint
• pnpm typecheck
• pnpm turbo build --force
• pnpm deadcode (existing configuration hints only)
• pnpm architecture:check
• pnpm turbo skills:build
• pnpm worker:performance-budgets

All commands ran with Node 24.18.0 and pnpm 11.15.0. Production validation before this fix also confirmed HTTP 206/16-byte delivery, ETag-backed 304, and invalid-range 416; the exact same flow will be repeated after deployment to verify the corrected Content-Range value.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
cheatcode	Skipped		Aug 25, 2026 11:03am

[iamjr15]

CI follow-up: the first run exposed that the global Worker budget command assumed every Worker dependency graph had already been built. This PR now adds an explicit all-Worker prerequisite build before measuring budgets; the command and actionlint both pass locally.