[kvz]

Why

The generated Storage release PR #655 cannot pass its Supabase Edge check: the fixture packs the local SDK, then npm tries to download its not-yet-published @transloadit/utils@^4.11.0 dependency. The original failure is ETARGET in CI run 43522561883. Retrying the same head cannot repair that dependency cycle.

What

• Pack this checkout's Utils once for packed-mode tests and install its tarball alongside each SDK tarball, as the existing upload-once fixture already does.
• Assert the installed lockfile actually resolves Utils from a local tarball, so published npm versions cannot silently replace the code under test.
• Preserve --version registry testing, optional dependency installation, pinned Supabase runtime, bundle budgets, runtime signature check and cleanup.
• No product runtime, dependency range, workflow or release-guard change; no package changeset needed for this harness-only fix.

Validation

• Red: the real generated release head 363d94e6 failed before bundling with No matching version found for @transloadit/utils@^4.11.0. Its log is retained; the remaining jobs on that unusable head were cancelled, not treated as passing.
• Green: applied only this patch to that exact generated release head in the existing configured checkout, without changing the generated remote branch. yarn test:sdk:edge passed for Node/legacy 6.9.0 with local Utils 4.11.0, including real Supabase ESZIP bundling and execution. No native image files; compressed bundles were 2,697,521 and 2,711,763 bytes, within the existing 5 MiB limit.
• Full yarn check passes on this task branch. The generated-version validation branch remains a local evidence pointer; no generated release files are in this PR.
• Council: two consecutive full-diff rounds clean before the first push; no review-driven code changes or extra CI pushes.

_{🤖 Claimed by kvz on framework1/node-sdk since 2026-11-13 · resume: codex resume 019fa2ee-f994-79d0-9d50-071bf2cb7ad6}