This question now blocks the same frozen 420-object compilation-only closure. Every required source member is locally readable and hashed, but we will not treat read access as proof of provider independence or deliberately trigger hydration. Could an Apple engineer confirm whether XATTR_FLAG_NEVER_PRESERVE and XATTR_FLAG_NO_EXPORT authorize deliberate non-preservation for this cross-volume compilation export, and identify the supported non-hydrating preflight that proves the closed tree is already materialized and will not request provider downloads? If no such preflight exists, what supported export procedure should be used? No production copy has been performed.

This question now blocks a bounded compilation-only staging plan. We have reduced the required source closure to a frozen allowlist of 420 filesystem objects, with independent source and destination inventories and byte-hash verification. The source would remain unchanged, and no Xcode build or test would begin unless staging verification passed. Could an Apple engineer confirm the supported destination treatment when a new object is created on a different APFS volume from source content carrying com.apple.macl: omit the attribute using data-only copying, preserve it, or use another supported API? Which destination postconditions demonstrate that access authority was neither widened nor broken? No production copy has been performed.