Storage class check can prevent deployments where no storage class is needed for the registry

[Racer159]

Environment

Device and OS: System76 darp8
App version: v0.32.2
Kubernetes distro being used: any (as long as they have no storage class)
Other: n/a

Steps to reproduce

1. Create a cluster without a storage class
2. Deploy the Zarf init package with an S3 or ephemeral registry

Expected result

Zarf successfully deploys

Actual Result

Zarf will fail with stating that it cannot find a storage class

Severity/Priority

Medium

Additional Context

There are work arounds with custom init packages but this use case should be handled since it is a regression from what the default Zarf init package used to be able to do.

[anthonywendt]

Was going to try a workaround. Seemed liked a bigger effort to get it back to 0.32.1 behavior. This stemmed from wanting to update to uds-cli v0.7.0 which uses zarf v0.32.2. I'm told that I should be able to use our custom zarf init v0.32.1 and should still work with the latest uds-cli even though it uses zarf v0.32.2. Its not always clear what versions of uds-cli are compatible with what versions of zarf. My assumption was they should always match? Will there always be NSYNC 🕺 versions of zarf and uds-cli? Could there be gaps?
defenseunicorns/uds-capability-rook-ceph#107