Enhance pagination and ordering capabilities in API responses

- Updated pagination-response and read-write-controllers documentation to include `orderBy` and `orderType` parameters for sorting results.
- Introduced new `order-clause` module to handle ordering logic, including validation for order types and columns.
- Enhanced `PaginationQueryDto` to support ordering fields in API requests.
- Updated various repository and service classes to implement ordering in database queries.
- Added unit tests for new ordering functionality and ensured existing tests cover the updated behavior.
- Refactored related DTOs to include user and code relations for better data representation in responses.

.cursor/rules/pagination-response.mdc

@@ -36,7 +36,7 @@ interface PaginationMeta {
 
 - Mark every list endpoint with `@Pagination()`
 - Return `{ data, total }` from the handler — **never** build `meta` in the service or controller
-- Query: `page`/`limit` or `offset`/`limit` (defaults `page=1`, `limit=10`; max limit `200`)
+- Query: `page`/`limit` or `offset`/`limit` (defaults `page=1`, `limit=10`; max limit `200`) plus `orderBy`/`orderType` (`ASC` | `DESC`, default `ASC`)
 - Use `@RawResponse()` for file downloads / health probes that must skip wrapping
 - Non-list handlers (detail, create, update, delete, status, import) pass through **unwrapped**
 

.cursor/rules/read-write-controllers.mdc

@@ -35,7 +35,7 @@ Register static write paths (`import`, `bulk-delete`, `bulk-status`) **before**
 List requirements:
 
 - Query filters for the resource’s own attributes **plus** `search` (case-insensitive match on the module’s searchable text columns; AND with other filters)
-- Shared pagination query (`page`/`limit` or `offset`/`limit`) via `PaginationQueryDto`
+- Shared pagination query (`page`/`limit` or `offset`/`limit`) plus `orderBy`/`orderType` via `PaginationQueryDto`
 - Handler **must** use `@Pagination()` and return `{ data, total }` — never build `meta` here (see `.cursor/rules/pagination-response.mdc`)
 - Service `visibleFields` whitelist: default **all non-secret** attributes; modules may narrow. Project in the **service**, not the controller
 - FK relations in list/detail (and write responses that reuse the mapper) MUST be nested objects via `pickRelation` — see `.cursor/rules/relation-response.mdc`