{Dataprotection} Preserve backup vault failures and enforce readiness

[FumingZhang]

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

Related command

az dataprotection enable-backup trigger

What / Why

Follow-up to #10309:

• Preserve backup vault discovery and creation errors rather than treating local validation/programming errors as unsupported storage types.
• Preserve the existing service-error storage-type fallback while surfacing full errors if all attempts fail.
• Require successful provisioning before configuring both new and reused vaults.
• Fail explicitly on bounded readiness exhaustion rather than continuing with an unready vault.
• Add regression coverage using the real AAZ command, request serialization, and asynchronous polling contract.

These changes repair error handling and readiness. Live backup creation has now passed in the validation subscription; this does not establish that every runner-subscription service restriction is resolved.

Validation

• Prior offline regression validation: 72 targeted tests and 32 subtests passed, including real AAZ serialization and HTTP 201/202 polling with mocked transport.
• Targeted live validation: test_aks_create_with_enable_backup and test_aks_update_with_enable_backup BOTH PASSED, using the existing westus2 test-location override (3301.37 seconds combined).
• Local dataprotection source loading and live mode were verified. test_aks_create_with_enable_backup PASSED live, creating AKS, storage, and a backup vault through the fixed helper.
• The live scenarios completed the eight-step backup orchestration, including extension, vault, policy, and backup-instance validation. Combined JUnit and JSON reports record two passes with no failures.
• Both tests' setup, call, and teardown passed in the final reports (1171.114 seconds for create; 2127.351 seconds for update). Scoped resource cleanup and removal of isolated credential copies are verified.
• No offline or mocked result is counted as a live test pass.

Scope / History

• Version bumped from 1.12.0 to 1.12.1, with a matching history note.
• Existing 1.12.0 Elastic SAN work is preserved; src/index.json is unchanged.

General Guidelines

• Have you run azdev style <YOUR_EXT> locally? (pip install azdev required) - targeted flake8/syntax checks passed; full repository style is left to 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

Version and history are updated; 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