PIM ARM Role Management Policy (List) returns a different "rules" object if you have made edits to it via the API

When I use the [Role Management Policies List API](https://learn.microsoft.com/en-us/rest/api/authorization/role-management-policies/list-for-scope?tabs=HTTP) on any object I haven't also edited via the Update API, it returns a response like the below***** :

```
scope : /subscriptions/5715b9e3-5625-447f-89ea-bed0a29e57a6/resourceGroups/MadeUp-RG
isOrganizationDefault : True
lastModifiedBy :
rules : {@{isExpirationRequired=True; maximumDuration=P90D; id=Expiration_Admin_Eligibility; ruleType=RoleManagementPolicyExpirationRule; target=}, @{enabledRules=System.Object[]; id=Enablement_Admin_Eligibility;
ruleType=RoleManagementPolicyEnablementRule; target=}, @{notificationType=Email; recipientType=Admin; isDefaultRecipientsEnabled=True; notificationLevel=All; id=Notification_Admin_Admin_Eligibility;
ruleType=RoleManagementPolicyNotificationRule; target=}, @{notificationType=Email; recipientType=Requestor; isDefaultRecipientsEnabled=True; notificationLevel=All; id=Notification_Requestor_Admin_Eligibility;
ruleType=RoleManagementPolicyNotificationRule; target=}...}
effectiveRules : {@{isExpirationRequired=True; maximumDuration=P90D; id=Expiration_Admin_Eligibility; ruleType=RoleManagementPolicyExpirationRule; target=}, @{enabledRules=System.Object[]; id=Enablement_Admin_Eligibility;
ruleType=RoleManagementPolicyEnablementRule; target=}, @{notificationType=Email; recipientType=Admin; isDefaultRecipientsEnabled=True; notificationLevel=All; id=Notification_Admin_Admin_Eligibility;
ruleType=RoleManagementPolicyNotificationRule; target=}, @{notificationType=Email; recipientType=Requestor; isDefaultRecipientsEnabled=True; notificationLevel=All; id=Notification_Requestor_Admin_Eligibility;
ruleType=RoleManagementPolicyNotificationRule; target=}...}
policyProperties : @{scope=}
```

Note the `isOrganizationDefault` setting is True. This role has not been touched in anyway. In this case, this is the Log Analytics Reader role policy above. If I then expand the _rules_ property specifically, this is what it looks like, consistent with what the response documentation says you should get back :
(screenshot trimmed for brevity)

However, after editing the policy via the [Update API](https://learn.microsoft.com/en-us/rest/api/authorization/role-management-policies/update?tabs=HTTP), I now get a rule attribute formatted completely differently. Exact same rule after being edited:
(comprehensive screenshot this time)

I've only edited the isExpirationRequired in my specific testing. I am using the APIs via the Invoke-RestMethod cmdlet in PowerShell. The different formatting returns the same even if it has been edited in the portal. The only difference I can trigger is if the API has made an update.

Quite frankly the second response is easier to read and handle I believe. Apparently it is the same content, but it threw me for a complete loop. That being said, is this change in response structuring intended?

*****I'm filtering for just a single policy related to a specific role, as is shown [here](https://learn.microsoft.com/en-us/rest/api/authorization/privileged-role-policy-rest-sample#list-role-management-policies-for-a-resource).

Start by comparing the linked Role Management Policies List API and Update API documentation, including their response examples and the PowerShell Invoke-RestMethod behavior described here. Determine whether the rules shape is expected to differ before and after an update; done means the response contract is clarified or the inconsistency is documented for correction.

Written by the indexing model from the issue text.