Modal handoff fails when one artifact tree is both a dependency and a reference

Summary

createModalNodeHandoffArchive fails with EEXIST when the same run-root artifact directory is declared in both dependency_artifact_dirs and reference_artifact_dirs.

This is a valid compiled handoff shape for an external Solidity target: the dependency list preserves the graph dependency while the reference list identifies the same tree's special planner/reference role. The provider copies the dependency tree first and then copies the reference tree to the same staged path with COPYFILE_EXCL, so the second copy fails before a Modal sandbox can launch.

Minimal reproduction

Using the existing generic createProjectFixture in packages/modal/test/node-provider.test.ts:

1. Select one fixture dependency artifact directory.
2. Set reference_artifact_dirs to an array containing that same directory.
3. Rebuild the agreeing selected_task DTO.
4. Call createModalNodeHandoffArchive(fixture.root, input).

Focused test name:

builds a handoff when one artifact tree is both a dependency and a reference

Observed result:

EEXIST: file already exists, copyfile '<temporary fixture>/artifacts/dependency-one/declared.txt' -> '<temporary handoff>/artifacts/dependency-one/declared.txt'
0 pass, 1 fail, 205 filtered out

The failure occurs in copyTreeChecked during the reference-artifact loop, after the dependency-artifact loop has already materialized the same destination.

Expected behavior

An exact dependency/reference overlap should be materialized once while remaining represented under both semantic labels in the content fingerprint and selected-task provenance. Safety checks must remain fail-closed for non-identical or unsafe paths.

Environment

• UltraFuzz release/v0.1.0 lineage
• Bun 1.3.0
• Modal provider package

Start with createModalNodeHandoffArchive and copyTreeChecked, then read packages/modal/test/node-provider.test.ts and the focused test named "builds a handoff when one artifact tree is both a dependency and a reference." The overlap should build successfully while retaining both semantic labels in the content fingerprint and selected-task provenance, with safety checks still rejecting unsafe or non-identical paths.