chore: restore config components fallback for zarf init

[amirHdev]

Summary

Fixes zarf init component selection from config files by adding a backward-compatible fallback.

zarf init now resolves components in this order:

1. init.components (preferred)
2. package.deploy.components (fallback when init.components is unset)

This addresses #4439 where users with existing zarf-config.yaml files using package.deploy.components saw components ignored during zarf init --confirm.

Changes

• Update init command default component resolution to support fallback:
  • src/cmd/initialize.go
• Add regression test coverage for fallback + precedence behavior:
  • src/test/e2e/29_config_file_test.go
• Clarify config docs for init.components vs package.deploy.components and fallback:
  • site/src/content/docs/ref/config-files.mdx

Why

Historically, some users relied on package.deploy.components for zarf init.
This change keeps init.components as the intended key while preventing breakage for existing configs.

Testing

• Added E2E test: TestInitComponentsConfigFallback
  • verifies fallback to package.deploy.components
  • verifies init.components takes precedence when both are set

Issue

• Closes zarf-config.yaml - package.deploy.components ignored during zarf init --confirm #4439

[netlify]

✅ Deploy Preview for zarf-docs ready!

Name	Link
🔨 Latest commit	e94c9bb
🔍 Latest deploy log	https://app.netlify.com/projects/zarf-docs/deploys/699afc5fd1df450008da2d12
😎 Deploy Preview	https://deploy-preview-4613--zarf-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

❌ Patch coverage is 57.14286% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/cmd/initialize.go	57.14%	2 Missing and 1 partial ⚠️

Files with missing lines	Coverage Δ
src/cmd/initialize.go	26.71% <57.14%> (+0.51%)	⬆️

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[brandtkeller]

Hey @amirHdev!

Thanks for this PR and I appreciate the consideration applied to backwards compatibility. The changes look correct.

Overall I don't have a hard opinion but I do feel that the changes we made to remove global state - which resulted in this change in behavior - ultimately provided the distinct separation between init components and package deploy components.

Given our push to refine the v1.0.0 and intentionally looking for logic to cleanup - I am unsure if we would want this backwards-compatibility in perpetuity.

Have you seen this negatively impacting many users for which they did not have control over correcting their zarf-config files?

[brandtkeller]

Hey @amirHdev ! Appreciate this PR and the time you took to understand the issue. Looking further into the root of the problem and believe we want to retain the current (fixed) behavior with regards to the separation of init vs standard package components. As such I am going to close this PR - but please let me know if you are interested in other issues or have new information regarding these changes.