Moved from 2.27 to 2.33 and all is broken

## Bug description
After we moved from 2.27 to 2.33 we wanted to spin up the project locally but all is broken. Obviously by default the project now assumes to use the ARM api instead of the direct REST as we had it configured in our config.design.json file. With the direct API we get only 404 errors at any backend call. So we figured that out and our configuration now looks like:

{
"environment": "development",
"managementApiUrl": "https://management.azure.com/subscriptions/_{/resourceGroups//providers/Microsoft.ApiManagement/service/",
"managementApiAccessToken": "Bearer ",
"backendUrl": "https://management.azure.com",
"directDataApi": true,
"dataApiUrl": "",
"useHipCaptcha": false
}}

after that change the 404 disappeared and the access works, is it normal that we always need to apply the bearer token here every hour then? how will this look like in the cloud, external basic users do not have a bearer token i guess, will this even work?

also we recognized that apiName and operationName as well as productName and other parameters now are not only the id but the full path /subscriptions/_{/resourceGroups//providers/Microsoft.ApiManagement/service//apis/}

this leads to not working api calls because this api name is concatenated to the URL in the routeHelper.js. so we had to remove this duplicated path using a split helper function in the routeHelper.ts, thats definitely a bug i would say.

after solving that we can get the data but when e.g. clicking on a individual api in the api list when the operations of the api get retrieved to be displayed on the left side there is a strange error when loading them, they can be loaded with a 200 (we see that in the logs) but then they cannot be mapped or something to the operation models to be displayed, i will attach the error message below, we tried to debug it but we fail.

## Reproduction steps

see description above

## Expected behavior

expected not having to be forced to use ARM api via a configuration, also not expecting to have to place token in the configuration all the time, also expecting that record ids do not contain the full path to the record and expecting that operations can be loaded.

## Is self-hosted portal?

Yes

## Release tag or commit SHA (if using self-hosted version)

2.33

## API Management service name

we do not want to publish that here

## Environment

running in an azure static web app

## Additional context

Error message loading operations:
Uncaught runtime errors:
×
ERROR
Unable to load operations: Error: Cannot read properties of undefined (reading 'includes')
at OperationList.eval (webpack://apim-developer-portal/./src/components/operations/operation-list/ko/runtime/operation-list.ts?:128:23)
at Generator.throw ()
at rejected (webpack://apim-developer-portal/./src/components/operations/operation-list/ko/runtime/operation-list.ts?:15:65)
ERROR
Unable to load operations: Error: Cannot read properties of undefined (reading 'includes')
at OperationList.eval (webpack://apim-developer-portal/./src/components/operations/operation-list/ko/runtime/operation-list.ts?:128:23)
at Generator.throw ()
at rejected (webpack://apim-developer-portal/./src/components/operations/operation-list/ko/runtime/operation-list.ts?:15:65)

Start by reproducing the 2.27-to-2.33 migration with the supplied config.design.json settings and trace the direct API requests. Inspect routeHelper.ts for duplicated resource paths, then inspect operation-list.ts around line 128 for the undefined value after operations return 200. Done means the configured API mode works without malformed record URLs and operations load in the portal.

Written by the indexing model from the issue text.