az vm update retains conflicting Capacity Reservation state when switching assignment modes

## Describe the bug

`az vm update` can retain conflicting persisted Capacity Reservation state when switching an existing VM between an explicit Capacity Reservation Group and disabled Capacity Reservation assignment.

If the existing VM has a `capacityReservationGroup` and the command explicitly sets `--disable-capacity-reservation-assignment true`, the outgoing update payload retains the group while also setting `disableCapacityReservationAssignment` to `true`.

The inverse transition has the same problem: when the existing VM has `disableCapacityReservationAssignment: true` and a real `--capacity-reservation-group` is assigned, the outgoing payload retains both properties.

`disableCapacityReservationAssignment: false` is valid alongside a Capacity Reservation Group and is not part of the defect.

## Related command

```text
az vm update --resource-group --name --disable-capacity-reservation-assignment true

az vm update --resource-group --name --capacity-reservation-group
```

## Errors

No CLI error is raised. Azure CLI instead constructs an outgoing request payload containing conflicting Capacity Reservation state:

```json
{
"capacityReservationGroup": {
"id": ""
},
"disableCapacityReservationAssignment": true
}
```

This report does not claim a particular service-side error or data corruption.

## Issue script & Debug output

I reproduced the behavior locally through the standalone VM update path and the generated AAZ request serializer.

Before the fix:

Existing CRG -> disable=true

```json
{
"capacityReservationGroup": {
"id": "CRG-A"
},
"disableCapacityReservationAssignment": true
}
```

Existing disable=true -> real CRG

```json
{
"capacityReservationGroup": {
"id": "CRG-B"
},
"disableCapacityReservationAssignment": true
}
```

For comparison, existing disable=false -> real CRG remains a valid state:

```json
{
"capacityReservationGroup": {
"id": "CRG-B"
},
"disableCapacityReservationAssignment": false
}
```

No live Azure request was sent as part of this local reproduction.

## Expected behavior

- Setting `--disable-capacity-reservation-assignment true` should remove a persisted Capacity Reservation Group from the outgoing update state.
- Assigning a real `--capacity-reservation-group` should remove persisted `disableCapacityReservationAssignment` only when that persisted value is `true`.
- Persisted or explicitly supplied `false` should remain valid with a Capacity Reservation Group.
- Omitted Capacity Reservation arguments and unrelated VM updates should preserve the existing state.
- A real Capacity Reservation Group combined with explicit `--disable-capacity-reservation-assignment true` should continue to be rejected by the existing CLI validation.

## Environment Summary

```text
azure-cli 2.90.0

core 2.90.0
telemetry 1.1.0

Dependencies:
msal 1.36.0
azure-mgmt-resource 24.0.0

Python location '/.venv/bin/python'
Config directory ''
Extensions directory '/cliextensions'

Python (Darwin) 3.13.11 (main, Dec 5 2025, 16:06:33) [Clang 17.0.0 (clang-1700.4.4.1)]

Legal docs and information: aka.ms/AzureCliLegal
```

Azure CLI 2.90.0 was the latest released version when this issue was reproduced.

## Additional context

The behavior is in the standalone `az vm update` state transition. The generated API model exposes `capacityReservationGroup` and `disableCapacityReservationAssignment` independently, while generic update begins with the existing VM state, so the command-specific update layer needs to reconcile the conflicting persisted value when the user explicitly switches assignment modes.

The issue is reproducible through the final AAZ serialized request content without sending a live Azure request.

The relevant standalone update behavior was added as part of #33901.