Plugin search API returns different result ordering when only per_page differs

The plugin search API at api.wordpress.org/plugins/info/1.2/ returns results in a different order depending on the per_page parameter, even when the search query and page number are identical.

Steps to reproduce:

1. Request: ​https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request[search]=backup&request[page]=1&request[per_page]=20
2. Request: ​https://api.wordpress.org/plugins/info/1.2/?action=query_plugins&request[search]=backup&request[page]=1&request[per_page]=36
3. Compare the slug order of the first 20 results.

Expected: The first 20 results from both requests should be in the same order, since only the number of returned items differs.

Actual: Both requests return the same set of 20 slugs, but the ordering differs in two places:

  ┌──────────┬─────────────────────────┬─────────────────────────┐
  │ Position │       per_page=20       │       per_page=36       │
  ├──────────┼─────────────────────────┼─────────────────────────┤
  │ 3        │ all-in-one-wp-migration │ duplicator              │
  ├──────────┼─────────────────────────┼─────────────────────────┤
  │ 4        │ duplicator              │ all-in-one-wp-migration │
  ├──────────┼─────────────────────────┼─────────────────────────┤
  │ 16       │ wp-mail-smtp            │ backup                  │
  ├──────────┼─────────────────────────┼─────────────────────────┤
  │ 17       │ backup                  │ wp-mail-smtp            │
  └──────────┴─────────────────────────┴─────────────────────────┘

Impact: wordpress.org plugin search uses per_page=20 while wp-admin Add Plugins uses per_page=36. This means users see different plugin rankings for the same search term depending on where they search. A plugin can appear at position 3 on wordpress.org but position 5 in wp-admin, or vice versa.

Likely cause: Elasticsearch's default query_then_fetch search type computes relevance scores per-shard using local term frequencies. Changing the result set size affects how shard results are merged, producing inconsistent global ordering. Using dfs_query_then_fetch would ensure consistent scoring across request sizes.