feat: add external data injection and fix registry prune resilience

[ljluestc]

This PR introduces a new feature for external data injection and improves the resilience of the registry prune command.

1. External Data Injection (Resolves #2121)

This feature allows users to inject data from the local filesystem at deploy time, rather than requiring the data to be bundled into the Zarf package during creation. This is particularly useful for large datasets, sensitive data, or dynamic data that is only generated at deploy time.

Changes:

• Updated ZarfDataInjection schema to include a type field (embedded | external).
• Updated zarf package create to skip bundling sources for external data injections.
• Updated zarf package deploy to resolve external sources using Zarf variables and pass the local path to the injection logic.
• Fixed SBOM generation to handle components that may not have a tarball (if they only contain external data).

2. Resilient Registry Prune (Resolves #2641)

The zarf tools registry prune command has been updated to handle missing image manifests gracefully. Previously, if the command encountered an image digest that was expected but missing from the registry (e.g., due to a failed push), it would error out.

Changes:

• The command now logs a warning when an image digest cannot be found and continues processing the remaining images.

[netlify]

✅ Deploy Preview for zarf-docs canceled.

Name	Link
🔨 Latest commit	45192e2
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/6925ed55b0ff9f0007ac7c9a

[AustinAbro321]

Hello @ljluestc, I appreciate the work you put into this PR! We are planning on deprecating data injections soon. Some of the reasons why are in PR #4068 and we are going to formally announce the intent to deprecate after #4334 is merged as that will give users an easier migration path.

Even without deprecating data injections, I do think there are some issues with solving this problem in this way. Two of the principals of Zarf packages are that they should be simple to deploy and deployable on any machine. These are not always true, but by adding the requirement of having a specific directory we move away from these principals.

I do believe that is worth a separate issue outside of the context of data injections and #2121. It's a common enough problem that Zarf should solve or assist in somehow.

One way that a user solve this now, without data injections today is by following a similar guide to what's laid out in #4068. However, instead of adding the data image to the package, a user would create a separate Zarf package in their deploy environment which solely pushes images with their data. This package would be deployed before the main package. Still not a perfect solution, your new package would have to assume that there are existing images in the registry, but I do think it's cleaner solution.

Also generally a PR should solve one item. I am closing this out, but I encourage you to create a separate PR for issue #2641