fix: bug in calculation of the next id in MultiTroveGetter

[EmperorOrokuSaki]

The function skips nodes when using continuation-based pagination.

When calling getDebtPerInterestRateAscending(collIndex, startId, maxIter), the function does:
currId = sortedTroves.getPrev(_startId);

This causes a skip when chaining calls. For example:

- Returns trove with 15% rate, debt: 12005.07
- currId: 46086...0131

Call 2: startId = 46086...0131, maxIter = 1
- Returns trove with 16% rate, debt: 17874.79
- currId: 77004...2374

But when fetching multiple at once:

Call 3: startId = 0, maxIter = 3
[
  [0x0, 15%, 12005.07],
  [0x8cf5..8460, 15.1%, 3546.81],  <-- This node was skipped in pagination
  [0x0, 16%, 17874.79]
]

The 15.1% trove is missing when paginating one by one because we're using the returned currId as the next startId. When we do this, getPrev(startId) skips over the startId node itself.

One fix would be modifying the startId logic in the function:
currId = _startId == 0 ? sortedTroves.getPrev(_startId) : _startId;

This would preserve the node we're starting from rather than skipping to its prev immediately.

The current workaround requires making an extra call to sortedTroves.getNext() between paginated fetches, but that adds some costs and latency that could be avoided with the suggested fix (and the IR canister should try to avoid it as much as possible as the calls take a long time already).

[danielattilasimon]

Looks good!

[danielattilasimon]

Good catch! We could also use sortedTroves.getLast() when _startId == 0, which might be more readable.