app config definition cursor pagination drops rows sharing a created_at

AppConfigDefinitionConditions.by_cursor_forward and by_cursor_backward compare created_at alone against the cursor row's created_at. The adapter's PaginationSpec orders the page by created_at with id as the tiebreaker, so rows that share the cursor row's created_at — every row inserted in one transaction, where now() is the same value — fall outside the predicate. A page requested after such a cursor comes back empty or skips the tied rows instead of continuing to the next row.

## Expected

- Paging with first and after continues to the next row in (created_at DESC, id ASC) order when created_at ties.
- Paging with last and before includes the tied rows before the cursor row.

## What it needs

Composite comparison in both predicates: forward reads created_at < cursor.created_at OR (created_at = cursor.created_at AND id > cursor.id); backward mirrors it with id < cursor.id.

## Acceptance

- A repository test with rows sharing one created_at walks forward from each row without a gap or a repeat.
- The same rows walk backward without losing the tied rows.

## Related

BA-6988 named this tie gap out of scope for every entity that uses the pattern; this issue closes it for app_config_definition only. Found while writing the app_config_definition scenarios (BA-7832, PR #14511), where the fix first landed inside the test PR and is now carried separately.

JIRA Issue: BA-7878

Start with AppConfigDefinitionConditions.by_cursor_forward and by_cursor_backward, then inspect the adapter's PaginationSpec ordering of created_at and id. Add repository coverage using rows sharing one created_at, walking forward and backward from each cursor. Done means tied rows are neither skipped nor repeated in either direction.

Written by the indexing model from the issue text.