What does this implement/fix? Explain your changes.

Cursor pagination silently dropped and duplicated results for searched post connections whenever search relevance order differed from date order. With 10 posts matching a search (6 matching in the title with old dates, 4 matching only in content with new dates), posts(first: 5, where: {search}) followed by the endCursor returned 1 result instead of 5 and reported hasNextPage: false, leaving 4 of 10 results unreachable.

Root cause

Two layers:

1. A guard added in #897 - Cursor pagination does not preserve order with the "search" where arg #898 to force date ordering for searches checks $query_args['search'], but the GraphQL input is mapped to s before the check runs, so it has been dead code since it was added.
2. With the guard inert, WP_Query applies its native relevance ordering (parse_search_order(), a CASE WHEN post_title LIKE ... THEN 1 ... expression prepended to the ORDER BY), but PostObjectCursor built its cutoff only from post_date/ID, so the WHERE clause and the ORDER BY disagreed.

Simply fixing the dead check (the approach in #1819) repairs pagination but forces searched results into date order, losing relevance ranking, which is why that PR was withdrawn in 2021. This PR keeps relevance ordering and makes the cursor understand it.

The fix

• PostObjectCursor: when WP_Query's native search ordering is active (search set, title ordering clauses present, no other orderby), the cursor prepends a comparison against the same relevance expression parse_search_order() generates, built from the same prepared LIKE clauses WP_Query stores in the query vars during parse_search(). The cursor node's rank is computed in PHP by evaluating the same conditions in the same order, and the existing date/ID comparisons remain as tiebreakers, matching the actual ORDER BY exactly (relevance, then post_date, then ID from the existing stability filter).
• Config: a new posts_search_orderby filter inverts the relevance expression for backward (last) pagination, mirroring how the date ordering is inverted, so backward queries read the tail of the relevance-ordered set.
• PostObjectConnectionResolver: the dead guard is removed (preserving relevance ordering as the default for searched connections, matching plain WP_Query/wp-admin behavior), and the post_parent unset for searches now correctly checks s.

Explicitly supplied orderby input is unaffected: it is mapped after this logic and already overrides search ordering, and the cursor only enters relevance mode when no other orderby is set.

Out of scope

Plugins that replace the search SQL entirely (e.g. ElasticPress) bypass both WP's relevance ordering and this cursor logic, unchanged from current behavior.

Does this close any currently open issues?

Fixes #1818 (also closes the loop on the dead code introduced via #898 / withdrawn fix #1819; #2550 was already closed as a duplicate of #1818)

Any other comments?

Regression tests use a fixture where relevance and date order genuinely differ (title matches are older, content-only matches are newer). The pre-existing search pagination tests never caught this because all their fixture posts match in the title with sequential dates, making relevance order identical to date order.

Coverage: forward single-term, forward multi-term (exercising the CASE expression path), and backward (last/before) against the relevance-ordered set, plus the full existing pagination suite (14 tests, 557 assertions, all passing). PHPCS and PHPStan (level 8) clean.

Verified end-to-end over HTTP against a wp-env site: page 1 returns relevance-ordered results, page 2 returns the remaining results with accurate pageInfo, and last: 5 returns the exact tail of the display order.