[BUG] automation: Runtime Environment Package CreateOrUpdate API should be a Long Running Operation (LRO)

### API Spec link

https://github.com/Azure/azure-rest-api-specs/blob/main/specification/automation/resource-manager/Microsoft.Automation/stable/2024-10-23/package.json

### API Spec version

2024-10-23

### Describe the bug

The PUT API for Runtime Environment Package (Microsoft.Automation/automationAccounts/runtimeEnvironments/packages) returns 200 OK immediately, but the resource is not actually ready — it goes through multiple intermediate provisioning states (Creating, ContentDownloaded, ContentValidated, RunningImportModuleRunbook, etc.) before eventually reaching Succeeded or Failed.

This means the API behaves asynchronously but is not modeled as a Long Running Operation (LRO). Clients must manually poll the GET endpoint and check provisioningState to know when the operation has actually completed.

### Expected behavior

The PUT API should be a proper LRO — it should return 201 Created with an Azure-AsyncOperation or Location header so that clients can use standard LRO polling.

### Actual behavior

The PUT API returns 200 OK with provisioningState: Created in the response body. The resource then transitions through multiple intermediate states asynchronously:

Created → ContentDownloaded → ContentRetrieved → ContentStored → ContentValidated → RunningImportModuleRunbook → Succeeded

Clients have no standard mechanism to wait for completion and must implement custom polling.

### Reproduction Steps

1. Create a Runtime Environment Package:
```
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/runtimeEnvironments/{runtimeEnvironmentName}/packages/{packageName}?api-version=2024-10-23

{
"properties": {
"contentLink": {
"uri": "https://devopsgallerystorage.blob.core.windows.net/packages/pswindowsupdate.2.2.1.5.nupkg",
"version": "2.2.1.5"
}
}
}
```
2. Observe the response is 200 OK with "provisioningState": "Created" — no LRO headers are present.
3. Poll the GET endpoint repeatedly:
`GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Automation/automationAccounts/{automationAccountName}/runtimeEnvironments/{runtimeEnvironmentName}/packages/{packageName}?api-version=2024-10-23`
4. Observe provisioningState transitions through intermediate states (ContentDownloaded, ContentValidated, RunningImportModuleRunbook, etc.) before reaching Succeeded approximately 30–60 seconds later.

### Environment

_No response_

Start with the linked specification/automation/resource-manager/Microsoft.Automation/stable/2024-10-23/package.json and inspect the Runtime Environment Package PUT operation. Compare its response behavior with the expected Azure LRO headers and provisioning states described here. Done means the API spec models the operation as a standard LRO and passes the repository's specification validation.

Written by the indexing model from the issue text.