Honour the cursor arguments the REST image search advertises

AdminSearchImagesInput documents two pagination modes and carries first, after, last and before, but the REST route (ImageAdapter.admin_search) assembles offset pagination by hand and reads only limit and offset. A caller that pages with a cursor is silently served the first page instead, with no error. The GraphQL route on the same adapter and the REST alias search already build through the shared builder and read both modes.

## Expected

- The REST image search reads the cursor arguments it advertises.
- Naming two pagination modes at once is refused, as it is on the GraphQL route and on the container registry search (BA-7859).

## What it needs

admin_search builds its querier through the shared builder with the image pagination spec, the way the GraphQL route and the alias search do, rather than assembling offset pagination by hand.

## Acceptance

- Paging with first and after walks the list rather than repeating the first page.
- A request naming both a cursor and a limit is refused.
- An adapter test covers each pagination mode and the refusal.

## Related

Same defect as BA-7859 on the container registry search. Found while writing the image adapter scenarios (BA-7837, PR #14520).

JIRA Issue: BA-7874

Start at ImageAdapter.admin_search and compare it with the GraphQL route and REST alias search, which use the shared builder and image pagination spec. Run or extend the image adapter scenarios to cover cursor and offset modes, mixed cursor/limit arguments, and refusal of both modes. Done means cursor paging advances through results and conflicting arguments are rejected.

Written by the indexing model from the issue text.