New logic VS/VCS

[kneumoin]

Description

This PR adds support for a VSC-only snapshot model in snapshot-controller and external-snapshotter sidecars.

With this change, VolumeSnapshotContent objects can be created and processed without a corresponding VolumeSnapshot.
This enables internal controllers (e.g. storage-foundation) to perform CSI snapshot and restore operations using
service-level APIs without exposing VolumeSnapshot resources to user namespaces.

The implementation is backward-compatible and preserves existing behavior for legacy
VolumeSnapshot-based workflows.

This change does not trigger restarts of control-plane components, ingress controllers,
or other critical cluster services.

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

Some internal Deckhouse components (virtualization, managed services, backup infrastructure)
require the ability to:

• create CSI snapshots of PVs,
• detach PVs from PVCs,
• restore PVCs from snapshots or detached PVs,

without creating VolumeSnapshot or temporary PVC objects in user namespaces.

The standard CSI snapshot workflow enforces a strict VolumeSnapshot ↔ VolumeSnapshotContent
binding, which makes it unsuitable for service-level, short-lived operations where:

• user-visible resources are undesirable,
• additional RBAC exposure is unacceptable,
• namespaces may be deleted shortly after the operation.

This PR removes the hard requirement for VolumeSnapshotRef in VolumeSnapshotContent
and allows snapshot-controller and sidecar-controller to work directly with VSC as the
source of truth, enabling a clean, secure, and minimal service workflow.

What is the expected result?

After applying these changes:

• VolumeSnapshotContent can be created without spec.volumeSnapshotRef.
• Snapshot-controller:
  • accepts and reconciles VSC-only objects,
  • adds finalizers and handles deletion correctly,
  • preserves legacy behavior when VolumeSnapshotRef is present.
• Sidecar-controller:
  • performs CreateSnapshot / DeleteSnapshot for VSC-only objects,
  • derives snapshot identity from VolumeSnapshotContent.UID when no VolumeSnapshot exists.
• No VolumeSnapshot objects are created implicitly.
• Existing VolumeSnapshot-based workflows continue to work unchanged.

Correctness can be verified by:

• creating a VolumeSnapshotContent without volumeSnapshotRef,
• observing successful CSI CreateSnapshot and ReadyToUse=true,
• deleting the VSC and observing CSI DeleteSnapshot execution.

Checklist

• The code is covered by unit tests (including VSC-only scenarios).
• e2e tests passed.
• Documentation updated according to the changes (to be done in storage-foundation ADRs).
• Changes were tested in the Kubernetes cluster manually.