ci: nested SDS E2E on skeleton

[yachmenevas]

Description

Add a minimal nested SDS E2E on top of the skeleton. Preserves triggers, dependencies, and ordering; replaces Ceph-only parts with SDS enablement (source: deckhouse) and nested replicated storage setup.

Why do we need it, and what problem does it solve?

Validate triggers/dependencies and SDS profile flow inside nested clusters before introducing full tests/notifications.

What is the expected result?

Workflow runs on schedule/dispatch/PR, boots a nested cluster, enables SDS modules, creates LVMVolumeGroups + ReplicatedStoragePool + ReplicatedStorageClass, and proceeds to E2E gates.

Checklist

• [ ] The code is covered by unit tests.
• [ ] e2e tests passed.
• [ ] Documentation updated according to the changes.
• [ ] Changes were tested in the Kubernetes cluster manually (workflow_dispatch).

Changelog entries

section: ci type: chore summary: "Add nested SDS E2E on top of skeleton (deckhouse source)."