[TASK] Refactor Angular routing to consume new portlet-url from backend

Description

The backend has been updated to decouple a portlet's internal ID () from its public URL.

The Old Way (Problem): Previously, the backend menu API generated URLs based on the portlet ID (e.g., analytics-search). To provide a user-friendly URL, we had to implement a workaround in our Angular routing to catch this path and redirect it to the desired path (e.g., analytics/search).

This image shows the exact hack we are now able to remove:

The New Way (Solution): The backend now provides a field, allowing the menu API to send the correct, final URL path (e.g., /analytics/search) directly.

This task is to refactor our Angular application to remove the now-obsolete redirect logic. We should update our routing configuration to expect and use the correct, user-friendly paths provided by the backend API.

Acceptance Criteria

All Angular route definitions that use a redirectTo for a portlet path (like the analytics-search example) are identified and updated.

Priority

None

Additional Context

No response

Start by searching the Angular routing configuration for route definitions using redirectTo with portlet paths, including the analytics-search example. Review how the menu API's portlet-url values are consumed, then remove obsolete redirects and update routes to use the backend-provided user-friendly paths. Done means all such redirectTo definitions are identified and updated.