{Dataprotection} Fix AKS backup storage and vault compatibility

[FumingZhang]

🤖 PR Validation — ️✔️ All clear

Breaking Changes
️✔️ None

This checklist is used to make sure that common guidelines for a pull request are followed.

Related command

az dataprotection enable-backup trigger, as used by az aks create/update --enable-backup.

What / Why

Follow-up to #10309:

• Preserve vault discovery and creation errors instead of treating local validation/programming failures as unsupported storage types.
• Keep service-error storage-type fallback while surfacing all errors when exhausted.
• Require successful provisioning for new and reused vaults, and fail explicitly on readiness exhaustion.
• Scope automatic storage discovery to the resolved backup resource group. A parallel live test previously reused another group's account and then configured the backup extension with the wrong group, causing ResourceNotFound.
• Use the selected storage account's actual resource-group/subscription identifiers when configuring the extension, including explicitly supplied accounts in another group. Propagate storage discovery errors instead of creating duplicates.
• Keep automatically provisioned AKS vaults on the supported 2025-07-01 create API to preserve their existing reversible soft-delete On/14-day behavior. The newly generated 2026-06-01 vault API rejects that setting with DppAlwaysOnSoftDeleteStateMandatory; silently enabling irreversible AlwaysOn would change existing behavior.
• This compatibility operation is scoped to AKS auto-provisioning. General backup-vault commands retain their newer API and cost-management functionality; custom/reused vault security settings are not changed.

Rebased after the intervening 1.13.0 release. The pending fix version is now 1.13.1, preserving 1.13.0's cost-management changes and the earlier Elastic SAN work.

Validation

September 17 live validation

• test_aks_create_with_enable_backup: passed, 1231.08 seconds.
• test_aks_update_with_enable_backup: passed, 2200.26 seconds.
• Both exact scenarios used the final storage-scope implementation and actual AKS, storage, extension, vault, policy, and backup-instance resources. Setup, call, and teardown all passed.
• Verified the loaded local helper and recorded matching source hashes before the runs. Used live mode with recording disabled and the existing westus2 location setting; no forced location was overridden.
• Independently read an actual newly created vault and verified Succeeded, soft delete On, and 14-day retention.
• Earlier failed/interrupted attempts remain recorded: the initial new-API run exposed the AlwaysOn requirement; a subsequent parallel run exposed the cross-group storage-reuse/configuration bug. Neither is counted as a pass.
• The paired test teardown update in {AKS} Repair live scenario dependencies and monitoring consistency #10315 uses the API supporting reversible soft delete for the test-owned vault and asserts the requested cleanup settings.
• Final cleanup verified no run-owned resource groups or test node resource groups remain. Isolated credential copies and scratch directories were removed; unrelated resources/configuration and the test logs were preserved.

Other validation

• 78 targeted dataprotection tests and 32 subtests passed, including actual AAZ validation/serialization, HTTP 201/202 polling, storage discovery scope, original-error propagation, and actual-account resource-group routing.
• A regression confirms the general generated vault create still uses 2026-06-01 and serializes cost-management settings; the AKS operation alone uses the compatible API.
• Combined focused core/preview/dataprotection suite: 255 tests and 94 subtests passed. These are not counted as live test passes.
• Historical September 9 backup create/update passes are retained separately from the final rebased validation.

These fixes do not claim to remove service restrictions, quota exhaustion, or provisioning failures in every runner subscription. Those errors remain visible.

Scope / History

• Version bumped from 1.13.0 to 1.13.1, with matching release notes.
• Existing release history and new general vault capabilities are preserved.
• No index change.

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required) - targeted syntax/diff checks and regression tests passed; full style remains with CI.
• Have you run python scripts/ci/test_index.py -q locally? (pip install azdev required) - index unchanged.
• My extension version conforms to the Extension version schema.

For new extensions:

• N/A - not a new extension.

About Extension Publish

Publish version 1.13.1 after review. The index is managed by release automation.

[azure-client-tools-bot-prd]

Hi FumingZhang,
Please write the description of changes which can be perceived by customers into HISTORY.rst.
If you want to release a new extension version, please update the version in pyproject.toml (or setup.py, if the extension has not migrated yet) as well.

[Yong Zhang (yonzhan)]

Dataprotection