Support the policy-based Cloud backup service

[adinvadim]

Context

REG.RU now exposes a separate policy-based Cloud backup service for current
server plans. Unlike the legacy per-server boolean, it has a service name,
schedule, retention policy, stopped/enabled lifecycle, manual copies, and
separate deletion semantics:

https://reg.cloud/support/cloud/oblachnyye-servery/rabota-s-serverom/rezervnoe-kopirovanie-oblachnyh-serverov

No public management contract for this product was found in the currently
published CloudVPS v1/v2 OpenAPI documents. The first-party panel contains
private GraphQL operations such as activateBackup, enableBackup,
disableBackup, deactivateBackup, updateBackup, and removeSnapshot, but
those browser-session operations are observable implementation details rather
than a published compatibility promise.

The new product must not be routed through the legacy
enable_backups/disable_backups action.

Phase 1: authorized contract capture

• Capture the current panel reads and mutations through an authorized test
  account without exposing cookies, CSRF values, service IDs, balances, or
  resource identifiers.
• Establish typed contracts for service inventory/detail, activation,
  enable/disable, update, deletion, snapshot inventory, manual snapshot,
  restore, and snapshot deletion where the panel actually supports them.
• Record required browser-session authentication and selected-environment
  context, result unions, idempotency gaps, billing behavior, destructive
  effects, and reconciliation reads.
• Confirm terminology: stop/resume versus delete, and which operations retain
  or destroy stored copies.
• Add redacted fixtures and a dated research/implementation contract.

Phase 2: CLI adapter

• Introduce a distinct experimental-private capability and command namespace
  for the policy-based service. Do not silently reuse the legacy vps backup
  boolean model; choose the final command tree after the capture establishes
  the resource hierarchy.
• Use the existing per-account browser-session broker. Secrets and private
  response bodies must remain inside that boundary.
• Fail closed on manifest/schema drift and unsupported result variants.
• Preserve the global mutation contract: dry-run performs no credential or
  network work, interactive confirmation or --force is required, and each
  mutation is dispatched at most once.
• Reconcile ambiguous and asynchronous outcomes with authoritative reads; do
  not infer success from HTTP or GraphQL transport success alone.
• Provide stable human, plain, and JSON output without leaking private
  provider payloads.
• Document the private/unsupported boundary and add unit plus captured-fixture
  tests.

Acceptance criteria

• The implementation is based on a dated, authorized, redacted capture rather
  than guessed GraphQL requests.
• Legacy and policy-based backup products remain separate in commands,
  capabilities, data models, and documentation.
• Unsupported provider drift returns a structured capability/contract error
  with no speculative fallback.
• Destructive operations clearly state whether copies or the complete service
  will be deleted.
• make check passes.

Open gate

Implementation is blocked until an authorized account with the policy-based
backup product is available for a bounded capture and live verification.