Stamp delete-protected marker on managed VS adoption and VSC create p…

[kneumoin]

Description

Stamp the authoritative unified-snapshot delete-protection marker
state-snapshotter.deckhouse.io/delete-protected: "true" on the CSI snapshot
objects that storage-foundation contributes to the unified snapshot tree:

• Managed VolumeSnapshotContent — the marker is put into the CREATE
  payload in the VolumeCaptureRequest controller (processSnapshotTarget),
  so the VSC is protected from the moment it first appears in the API.
• Adopted VolumeSnapshot — the marker is stamped in the same patch
  that latches domain adoption (managed=true) in the VolumeSnapshot domain
  controller, before any graph edge is published. A vetoed VolumeSnapshot
  (managed=false) is a plain CSI snapshot, not a tree node, and is
  deliberately left unprotected.

This is the storage-foundation half of the cross-repo unified-snapshot delete
protection; the normative contract and the admission enforcement (the
ValidatingAdmissionPolicy) live in state-snapshotter
(design/delete-protection-contract.md). This PR only marks objects — it
does not enforce anything by itself and does not change VCR
lifecycle/retry/CSI semantics.

Reviewer note / merge blocker. images/controller/go.mod currently
carries a temporary local-dev replace for
github.com/deckhouse/state-snapshotter/api => ../../../state-snapshotter/api
(the module provides LabelDeleteProtected / StampDeleteProtected). This
must be swapped for a real published state-snapshotter/api version bump
before merge/CI — CI will not resolve the sibling path. The change is purely
additive (new constant + helper); the pinned consumer SDK is untouched, so no
SDK migration is pulled in.

No critical cluster components are restarted by this change.

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

Objects created/adopted by storage-foundation (managed VS/VSC) are structural
nodes of a unified snapshot tree. They must never be observable in an
unprotected state: there is no ordering guarantee between a Create and a
follow-up Patch, so stamping the marker after creation would leave a short
window in which the node could be deleted directly, corrupting the tree. Adding
the marker into the CREATE payload (VSC) and into the adoption-latch patch (VS)
closes that window and lets the state-snapshotter admission guard protect the
whole tree consistently once enforcement is switched to Deny.

What is the expected result?

• A newly created managed VolumeSnapshotContent carries the label
  state-snapshotter.deckhouse.io/delete-protected=true immediately on
  creation.
• A VolumeSnapshot gains the marker in the same update that sets
  …/managed=true; a vetoed (managed=false) VolumeSnapshot MUST NOT carry the
  marker.
• No change to VolumeCaptureRequest reconcile/retry behavior or CSI snapshot
  data-path.
• With the state-snapshotter delete-guard at enforcement: Deny, direct
  deletion of these marked objects is rejected (verified there); with Audit
  (default) nothing is blocked.

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.