List contracts, newest-ingested first (`id DESC`, the PK order — no user sort). `filter[type]` narrows by class, `filter[q]` searches id/name. Cursor-paginated like every other list endpoint.

Pagination metadata attached to list responses.

Cursor-based pagination (not offset) — see ADR 0008. Aligns with Stellar Horizon conventions and produces stable listings even when the underlying ledger stream advances between requests.

Both next_cursor (forward / next page) and prev_cursor (backward / previous page) are always emitted as opaque base64-JSON strings or explicit JSON null. Wire shape always carries both keys — never omitted — so the OpenAPI nullable: true declaration matches the on-wire bytes exactly. Option<String> carries the entire signal:

• next_cursor: null ⇒ last page (no further forward continuation).
• next_cursor: "..." ⇒ a further forward page exists.
• prev_cursor: null ⇒ first page (no backward continuation).
• prev_cursor: "..." ⇒ a backward page exists.

Both cursors carry an internal dir discriminant (see crates/api/src/common/cursor.rs::Direction) so the backend can branch SQL between forward (DESC <) and backward (ASC >, reverse for presentation) walks. Clients treat the strings as opaque tokens — round-tripping them through ?cursor= is the only expected use.