feat(search-api-graphql): add a declarative tie-break for sorted queries

[ddeboer]

Sorted by date, all datasets in a catalog registered at once share a datePosted, and Typesense returns such ties in insertion order. A reindex inserts them in a different order, so a client paging through the block can see a dataset twice or miss one.

A search type can now declare a tie-break in its GraphQL options:

types: {
  Dataset: { tieBreak: [{ field: 'title', direction: 'asc' }] },
},

• It is appended after the sort the request and queryDefaults settled on. A term on a field already sorted on is skipped.
• A query without a sort keeps the engine’s default order (relevance, or the collection’s defaultSortingField). To break ties there too, set a default sort in queryDefaults.
• Facet-only queries (perPage: 0) get no tie-break.
• Schema build rejects a tie-break on a field that isn’t sortable (Typesense has no sort index for it) and one longer than two terms (Typesense sorts on three at most, and one is the primary sort).
• The Typesense compiler rejects more than three sort terms with an error naming them, which covers a queryDefaults policy that sets two.

An integration test writes six documents with the same date, pages through them, rebuilds in reverse insertion order and gets the same order both times. Without the tie-break the rebuild does reshuffle them.

Not fully deterministic. Datasets with the same title still come back in storage order. A unique final key would need a sortable copy of the id in every collection, because Typesense can’t sort on id (tested on 30.2: a declared id field is dropped, and sort_by=id fails). We decided the extra field and reindex aren’t worth it for rare exact title ties.

Fix #866