Deprecate the module and hand CSI snapshots over to storage-foundation, keeping it standalone (v0.2.0)

[github-actions]

Description

Single deprecated release (v0.2.0) that consolidates snapshot support into the
storage-foundation module. It merges the two previously separate changes
(destructive-hook removal + deprecation/CRD-handover) into one PR and does not
remove the CRDs from the bundle.

Changes:

• Deprecated stage; removed auto-enable in every bundle (still explicitly enable-able).
• No storage-foundation requirement — the module stays INDEPENDENTLY installable.
  A cluster that does not enable storage-foundation still gets a working
  snapshot-controller (its templates render while storage-foundation is absent) plus the
  deprecation alert, instead of losing snapshot support. When storage-foundation IS
  enabled, the existing guard empties this module down to just the alert and
  storage-foundation owns the (byte-for-byte identical) CRDs.
• requirements.deckhouse: ">= 1.76" (new d8 baseline).
• Ships the three snapshot.storage.k8s.io CRDs as byte-for-byte copies of the
  storage-foundation ones (extended VolumeSnapshot with spec.mode), so both modules can
  apply identical definitions without conflict. The bundled controller is upstream (vanilla)
  external-snapshotter; it keeps reconciling snapshots against the extended CRDs because the
  fork is a backward-compatible superset (spec.mode is defaulted Capture/immutable and
  dropped by the typed client; VolumeSnapshotContent.volumeSnapshotRef is relaxed to optional;
  all required/CEL constraints hold for Capture-mode snapshots).
• Removed the destructive on-delete hook that stripped finalizers from VolumeSnapshot,
  VolumeSnapshotContent and VolumeSnapshotClass when the module was disabled (these objects
  are now shared with storage-foundation; disabling the module must not touch them). Also
  removed the unused snapshot-validation-webhook certificate hook and its values schema.
• Added the D8SnapshotControllerModuleDeprecated alert (PrometheusRule in d8-monitoring,
  severity_level: "9", expr: vector(1)), unguarded so it fires whenever the module is enabled.

Impact on critical cluster components: no control-plane / ingress / Prometheus restarts. The
module is no longer auto-enabled, but any cluster with it explicitly enabled keeps its
snapshot-controller workload (while storage-foundation is absent). Operators of an enabled
module will see the deprecation alert (severity 9). Disabling the module no longer removes
finalizers from snapshot objects.

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

storage-foundation is the owner of CSI snapshot support in the unified-snapshots architecture,
so snapshot-controller is being deprecated. It must be handed over safely: no cluster may lose
snapshot functionality, and existing snapshot objects must not break when the module is disabled.
Dropping the storage-foundation requirement (vs the earlier handoff design) is deliberate — a
cluster that has not enabled storage-foundation must still receive a functioning
snapshot-controller plus a migration nudge, not an inactive module and no snapshots.

What is the expected result?

• Enabling the module without storage-foundation: full snapshot-controller workload is
  rendered and CSI snapshots work against the extended CRDs; the deprecation alert fires.
• Enabling it with storage-foundation: the guard leaves only the deprecation alert; no
  workload/RBAC/webhook resources are rendered; storage-foundation serves snapshots and owns the
  CRDs.
• Disabling the module does NOT strip finalizers from VolumeSnapshot / VolumeSnapshotContent /
  VolumeSnapshotClass.
• The three snapshot CRDs remain Established (byte-for-byte identical to storage-foundation's);
  existing VolumeSnapshot objects keep their UID and ready/bound state.

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.