[Contribution Request] Fix candidate ordering issue in ACT_RU_IDENTITYLINK

Title: Inconsistent Candidate Order Due to Secondary Index Usage in ACT_RU_IDENTITYLINK

Description: When querying candidates in the ACT_RU_IDENTITYLINK table using the following SQL:

SELECT * FROM ${prefix}ACT_RU_IDENTITYLINK WHERE TASK_ID_ = #{parameter}

The returned candidate order is incorrect.

Root Cause Analysis:

With small data volumes: MySQL performs a full table scan. In InnoDB, a full table scan traverses the clustered index (primary key), so the results are naturally returned in primary key order. The candidate sequence is correct in this scenario. With large data volumes: After adding a secondary composite index on (TASK_ID_, USER_ID_), the query optimizer chooses this secondary index to improve performance. However, the result set is then returned in the order of the secondary index rather than the primary key. This breaks the expected primary key ordering and leads to inconsistent candidate sequences.

Expected Behavior: The candidate order should remain consistent regardless of the table size or the execution plan chosen by the optimizer.

Proposed Solution: To guarantee a deterministic order, an explicit ORDER BY clause (e.g., ORDER BY ID_ ASC) should be added to the query. Relying on the implicit ordering of a full table scan is an implementation detail and not a reliable guarantee.

MyFix