fix: disambiguate duplicate PR package graph edges

[patrikduksin]

Problem

PR-package graphs rewrite workspace dependencies to same-commit tarball URLs. When the same URL occurs on multiple edges (for example, a dependency of both the root package and several siblings), Bun through 1.3.14 can drop a late duplicate edge during installation and report a false failed to resolve. The upstream fix is oven-sh/bun#35426. In alchemy's real 12-package graph, the existing workflow reproduced the failure in 6/6 fresh installs (evidence), even though every URL returned the correct tarball and installed successfully by itself.

Query parameters are not a safe identity workaround. Bun retains the literal ? in its package-store directory name, then misparses that path during runtime module resolution; installation can finish while the installed CLI still fails. The identity therefore needs to be part of the publisher tag/path, not the query string.

Design

• During each pack job, derive duplicate workspace dependency targets from the complete selected plan. Only targets used by more than one workspace edge are disambiguated, so graphs without duplicate edges retain their existing manifest URLs byte-for-byte.
• Give every affected edge a deterministic tag of the form graph-<sha>-from-<parent>, stripping the parent's npm scope and bounding unusually long identities for Bun's package-store filename limit. The rewritten dependency URL points at that tag path.
• During publish, inspect all collected tarball manifests and accumulate the complete tag set for each dependency before uploading anything. This is deliberately publish-side: pack jobs are independent matrix jobs and cannot share tag state. Dependency uploads still complete before public commit/branch/PR tags are exposed.

Verification

Exercised the real reusable-workflow sequence with this branch: plan-pr-packages.ts → the caller's exact per-package build command → pack-pr-package.ts for all 12 packages → publish-pr-package-graph.ts. The source was alchemy-run/alchemy@016c375061706811664c7a1f0c36a0d948173cca with recorded submodules cloudflare-tools@0882b5ca2b00cb3349bff056f7547bf045495088 and distilled@c18cbf11b61e5223380107a98e6c7b1c822baddb. Test uploads went to pkg.patrikduksin.com under a collision-safe synthetic branch tag with a one-hour TTL; no production tags were reused.

• all 12 public URLs and all derived edge-tag URLs returned HTTP 200
• all packed manifests contained zero workspace: references and zero ? identities
• manifests with no disambiguated edge were byte-identical to the baseline workflow output
• three fresh Bun 1.3.14 bun add alchemy@<published-url> runs succeeded (the previous scenario failed 6/6)
• after adding the two independently published tools, all 12 configured packages were present in each clean project; installed graph manifests contained zero workspace: references and no node_modules path contained ?
• bun run alchemy --help exited 0 in all three projects after installing alchemy's declared optional Bun/Node platform peers
• bunx tsc --noEmit passed in the actions checkout

[BlankParticle]

Correctness issue: scoped parent names can still collide

graphEdgeTag() strips the parent npm scope. As a result, @scope-a/core and @scope-b/core both generate graph-<sha>-from-core. If both depend on the same workspace package, those duplicate edges still use an identical URL, so the Bun resolution failure this PR addresses can remain. An unscoped core also collides with either scoped package.

The identity should retain the full parent name or always append a bounded hash derived from the full name, for example from-core-<hash("@scope-a/core")>.

Commented on behalf of @BlankParticle by GPT 5.6-sol