uds deploy <OCI_URL> pulls package from outside bundle

[JaseKoonce]

Environment

Device and OS:
Linux
App version:
uds cli 18.0.0
Kubernetes distro being used:
EKS 0.31.0

Steps to reproduce

1. run `uds deploy oci://some_bundle_in_an_oci_registry

Expected result

I would expect that uds would utilize the packages already stored in the bundle artifact just as it does when deploying a local uds bundle.

Actual Result

UDS only uses the "bones" of the uds bundle then re-pulls the zarf packages as it hits each component

Visual Proof (screenshots, videos, text, etc)

From uds logs
note the pulling of individual component during the deployment:

DEBUG   2024-12-12T21:32:21Z  -  Pulling: uds-core (2.46 GBs of 2.79 GBs)
└ (/home/runner/go/pkg/mod/github.com/zarf-dev/zarf@v0.41.0/src/pkg/utils/bytes.go:117)
     ERROR:  failed to deploy bundle: unable to load the package: failed to copy content to /tmp/zarf-4232600858/images/blobs/sha256/**removed**: copy failed: unexpected EOF

  DEBUG   2024-12-12T21:32:21Z  -  Pulling: uds-core (2.46 GBs of 2.79 GBs)
└ (/home/runner/go/pkg/mod/github.com/zarf-dev/zarf@v0.41.0/src/pkg/utils/bytes.go:117)
     ERROR:  failed to deploy bundle: unable to load the package: failed to copy content to /tmp/zarf-4232600858/images/blobs/sha256/**removed**: copy failed: unexpected EOF

DEBUG   2024-12-12T21:37:21Z  -  Pulling: zarf-init-s3-irsa (559.44 MBs of 670.75 MBs)
└ (/home/runner/go/pkg/mod/github.com/zarf-dev/zarf@v0.41.0/src/pkg/utils/bytes.go:117)
  DEBUG   2024-12-12T21:37:21Z  -  Pulling: zarf-init-s3-irsa (561.49 MBs of 670.75 MBs)
└ (/home/runner/go/pkg/mod/github.com/zarf-dev/zarf@v0.41.0/src/pkg/utils/bytes.go:117)
     ERROR:  failed to deploy bundle: unable to load the package: failed to copy content to /tmp/zarf-2046928466/components/tofu-init.tar: copy failed: unexpected EOF

We see the EOF errors because of an unstable network connection, getting these errors at the first bundle pull is what would be more expected. Seeing them mid-way through a deployment can be problematic for the state of the deployment. Additionally I wouldn't expect to have to re-pull these components after already pulling the entire bundle in

Severity/Priority

med

Additional Context

Able to work around this by pulling the package locally and deploying the local package