Description

getLatestEpochParameters() fetches with Limit.of(1) and takes the first element from the response array. However, the /epoch_params endpoint does not guarantee ordering, and behind a load balancer different Koios nodes may be at different sync states. This means [0] can occasionally come from a stale node and return outdated parameters.

Reproduction

Running the following curl against preview repeatedly demonstrates the issue — [0] intermittently returns fewer PlutusV3 cost model entries than expected:

# Uses [0] like the Java client — occasionally returns stale result (e.g. 297 instead of 350)
curl -s "https://preview.koios.rest/api/v1/epoch_params" | jq '.[0].cost_models.PlutusV3 | length'

# Using max_by epoch_no always returns the correct latest result
curl -s "https://preview.koios.rest/api/v1/epoch_params" | jq 'max_by(.epoch_no).cost_models.PlutusV3 | length'

Expected behaviour

getLatestEpochParameters() should always return the most recent epoch's parameters.

Suggested fix

Add explicit descending sort on epoch_no so [0] is always the latest epoch:

Options options = Options.builder()
    .option(Limit.of(1))
    .option(Order.by("epoch_no", SortType.DESC))
    .build();

This is consistent with how PostgREST ordering works (?limit=1&order=epoch_no.desc), which consistently returns the correct result.