[SQL] Add short-term backup retention immutability support

[svmicano]

Related command

• az sql db str-policy set, show, and wait
• az sql midb short-term-retention-policy set and show (live and restorable dropped databases)

Description
Add short-term backup immutability support using 2026-08-01-preview, matching the behavior in Azure/azure-powershell#30215.

• Add nullable --lock-immutability and --yes/-y to both set commands. Only true prompts, with an irreversible-action warning. Cancellation sends no update and emits no result; non-interactive callers must use --yes when locking.
• Reject --lock-immutability together with --deleted-time, including explicit false, and never include that property in a dropped MI database request.
• Surface the service's immutabilityStatus on set/show for SQL Database and live/dropped MI databases while preserving flattened CLI output.
• Allow SQL Database lock-only/differential-interval-only changes without sending omitted settings as null. Preserve required retention days for MI and zero retention for dropped MI databases.
• Use shared SDK-independent AAZ HTTP/polling operations behind the existing command registrations. Preserve URL escaping, cloud endpoints, authentication, --ids, SQL DB wait, and --no-wait behavior.
• Keep azure-mgmt-sql==4.0.0b22 unchanged. The referenced https://pypi.org/project/azure-mgmt-sql/5.0.0b2/ introduces hybrid models and unrelated breaking changes; a whole-module SDK migration is deliberately out of scope.
• Update help and add 22 offline tests, including real CLI parsing, prompt accept/decline/no-TTY, explicit false/omission, dropped MI guards, errors, Location/async polling, IDs, wait and help.

Draft / before marking ready

• Re-record test_sql_db_short_term_retention and test_sql_managed_db_short_retention against the new API using dedicated test resources. Both existing playbacks fail: their recordings use 2024-11-01-preview; an in-memory diagnostic override additionally confirmed old polling recordings do not cover the new final-state-via: location contract. No recording files or matchers were changed.
• Complete live validation of immutability status, locking, and rejection of retention decreases on dedicated resources. Locking is irreversible; no live lock operations were performed during development.
• Run full SQL lint/scenario validation in the standard development environment. Full-module local Pylint could not resolve compiled-only dependencies in the installed CLI runtime and also reported existing findings; it is not claimed as passing.

Testing Guide
Completed locally against the edited CLI/core source with installed Azure CLI libraries (Python 3.14.6):

• python -m unittest azure.cli.command_modules.sql.tests.latest.test_sql_str_policy: 22 tests passed.
• All five affected command help pages execute successfully (covered by tests).
• Pylint with repository configuration for the new STR operation module: 10.00/10, no findings.
• pycodestyle for both new files, plus git diff --check: passed.
• Existing STR scenario playbacks: 2 failed, requiring new recordings as described above.

In a configured developer checkout, run the unit-test command above. For manual service validation, use dedicated disposable resources:

• az sql db str-policy show --resource-group MyGroup --server MyServer --name MyDb --query immutabilityStatus
• az sql db str-policy set --resource-group MyGroup --server MyServer --name MyDb --lock-immutability true prompts; decline to verify no update. Accepting is irreversible.
• az sql midb short-term-retention-policy set --resource-group MyGroup --mi MyInstance --name MyDb --retention-days 7 --lock-immutability true --yes deliberately skips that confirmation. This locks immutability irreversibly.
• Supplying either --lock-immutability true or false with --deleted-time must fail before any request.

History Notes
[SQL] az sql db str-policy: Add short-term backup immutability locking with confirmation and expose immutability status
[SQL] az sql midb short-term-retention-policy: Add immutability locking for live databases and expose status for live and dropped databases

---

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

• The PR title and description has followed the guideline in Submitting Pull Requests.
• I adhere to the Command Guidelines.
• I adhere to the Error Handling Guidelines.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Yong Zhang (yonzhan)]

Please fix CI issues