Update configs on js side to mitigate migration breakings

[kazrael2119]

This directive is to keep the orignal parameter order and to mitigate the un-necessary breaking introduced by migration.

[github-actions]

Next Steps to Merge

✅ All automated merging requirements have been met! To get your PR merged, see aka.ms/azsdk/specreview/merge.

Comment generated by summarize-checks workflow run.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Go	sdk/resourcemanager/postgresql/armpostgresqlflexibleservers
JavaScript	@azure/arm-keyvault
Java	com.azure.resourcemanager:azure-resourcemanager-postgresqlflexibleserver
Python	azure-mgmt-keyvault
Python	azure-mgmt-postgresqlflexibleservers
Java	com.azure.resourcemanager:azure-resourcemanager-keyvault-generated

[qiaozha]

@mikeharder in this case, the readme.md is defined this way, from my understanding the default tag should be package-flexibleserver-2025-08-01, which doesn't have the multiple api version issue, and the tag package-2020-01-01 should be recognized when package-singleservers option exists to satisfy the yaml expression, which shouldn't have existed in the pipeline and this package-2020-01-01 has the version uniform issue.
Now the CI is reporting this multiple api version failure, which indicates it's treating the 2020-01-01 as the default tag, I wonder why?

``` yaml
title: PostgreSQLManagementClient
description: The Azure Database for PostgreSQL management API provides create, read, update, and delete functionality for Azure PostgreSQL resources including servers, databases, firewall rules, network configuration, security alert policies, log files and configurations with new business model.
openapi-type: arm
tag: package-flexibleserver-2025-08-01
```

``` yaml $(package-singleservers)
tag: package-2020-01-01
```

[mikeharder]

@mikeharder in this case, the readme.md is defined this way, from my understanding the default tag should be package-flexibleserver-2025-08-01, which doesn't have the multiple api version issue, and the tag package-2020-01-01 should be recognized when package-singleservers option exists to satisfy the yaml expression, which shouldn't have existed in the pipeline and this package-2020-01-01 has the version uniform issue. Now the CI is reporting this multiple api version failure, which indicates it's treating the 2020-01-01 as the default tag, I wonder why?

``` yaml
title: PostgreSQLManagementClient
description: The Azure Database for PostgreSQL management API provides create, read, update, and delete functionality for Azure PostgreSQL resources including servers, databases, firewall rules, network configuration, security alert policies, log files and configurations with new business model.
openapi-type: arm
tag: package-flexibleserver-2025-08-01
```

``` yaml $(package-singleservers)
tag: package-2020-01-01
```

We can continue the discussion in the issue I opened:

• [MULTIPLE_API_VERSION] Detects wrong default tag avocado#236

Going forward, for questions like this, please open an issue (in the specs repo, or the repo of the specific tool), rather than just mentioning me in a GitHub comment. This ensures the question is tracked to completion and won't be forgotten, allows the issue to be assigned an owner, etc.

Also, please try to check the code for answers to questions like this. You can search the Avocado repo for the MULTIPLE_API_VERSION to find the related code. Or run avocado locally, and attach a JS debugger, to see why it's detecting the wrong default tag.

[sandipsh]

please address avocado failure.

[sandipsh]

please address avocado failure.

Oh i noticed avocado error is approved

[qiaozha]

Going forward, for questions like this, please open an issue (in the specs repo, or the repo of the specific tool), rather than just mentioning me in a GitHub comment. This ensures the question is tracked to completion and won't be forgotten, allows the issue to be assigned an owner, etc.

@mikeharder as you are the tooling owners, I can't be 100% sure if it's a tooling issue or not without your double confirming. If you missed the thread, I could remind you in teams or start an email thread or whatever ways you prefer.

You can double confirm and wait for me to create an issue for that the next day (as the time differences) if you think it's necessary and time efficient to do this way.

Also, please try to check the code for answers to questions like this. You can search the Avocado repo for the MULTIPLE_API_VERSION to find the related code. Or run avocado locally, and attach a JS debugger, to see why it's detecting the wrong default tag.

@mikeharder My understanding is that misrecognized the default tag isn't just a problem for MULTIPLE_API_VERSION. It's a general baseline setting for many different rules. Even this issue is reported when I review the MULTIPLE_API_VERSION issue, it has general impact on other rules as well.
Hence, I don't think I am suitable for pointing fingers to your tooling and also, I don't have bandwidth for this right now.