Align SDK contract types

When updating generated PowerShell/SDK clients (e.g., AutoRest v3 → v4), treat the generated model contract as authoritative: match namespaces/types and ensure request serialization shape matches what the REST service expects.

Do

• Update type references to the v4 flattened namespaces (don’t keep v3 versioned model types).
• Apply enum→string and other contract-shaped changes in parameters as-is.
• For parameters involving collections/identity dictionaries, preserve the generated model shape. If the SDK now defines String[], it will serialize as an array—AutoRest will not convert that into a hashtable/dictionary.
• Update tests to assert fields based on the API version actually used (and use instance view expansions when required). Prefer SDK cmdlets for assertions when they expose the property; otherwise assert via REST for the missing fields.

Don’t

• Assume backwards-compatible behavior (e.g., that a hashtable input will still be produced, or that enum-typed parameters can remain unchanged).

Example (identity shape change)

# AutoRest v4 style: array of ARM resource IDs
[Parameter(Mandatory=$false)]
[System.String[]] $UserAssignedIdentity

# SDK will serialize $UserAssignedIdentity as a JSON array.
# If the service still expects a dictionary/hashtable payload,
# update the service contract instead of trying to “fix” it in the cmdlet.

Use this checklist during migrations and related API interface work to avoid subtle request/response contract breaks and mismatched serialization payloads.