[BUG]Cursor pagination breaks when RBAC filtering is applied in `AuthorizedSubmodelRepository`

[geso02]

Description

When role-based access control (RBAC) is active, the AuthorizedSubmodelRepository filters submodels and submodel elements based on the current permissions. However, the current implementation applies filtering before pagination, which leads to the following issues:

• Pages may appear empty, even though data exists beyond the current page — just not visible due to access restrictions.
• Cursor information from the decorated repository is not preserved, which can break proper paging behavior.

---

Example scenario

• A user requests: GET /submodels?limit=5
• There are 20 submodels in total, but the user only has access to 1 of them.
• The RBAC logic filters the list to 1 submodel before pagination.
• Result: Only one submodel is returned, no correct cursor is provided, and further paging is no longer possible.

---

Expected behavior

• Pagination should be applied on the full data set returned by the decorated repository.
• RBAC filtering should happen after pagination.
• If the filtered result is too small, additional data should be fetched (refetch loop).
• The cursor from the original result set should always be passed through transparently.

---

Suggested fix

Refactor AuthorizedSubmodelRepository#getAllSubmodels(...) and getSubmodelElements(...) to use a pagination-aware authorization wrapper (similar to the one already used in the Submodel Service).

Reference implementation:

• FilteringBasyxResourceFetcher
  (used in basyx.submodelservice-feature-authorization)
  This class refetches pages until the filtered result matches the requested limit or the decorated source is exhausted.

---

Additional notes

This bug may lead to unpredictable behavior in frontends using cursor-based paging, especially when large sets of inaccessible resources are present in the repository.

[geso02]

⚠️ Additional security concern

Reusing the original cursor from the full (unfiltered) backend result may leak information about inaccessible resources, since the cursor is typically derived from internal resource identifiers (e.g., Base64-encoded idShort of a SubmodelElement).

To avoid exposing IDs of resources the client is not authorized to access, the cursor should be based on the last visible (i.e., authorized) element in the filtered result set.

The FilteringBasyxResourceFetcher used in the Submodel Service handles this correctly.