Order Query API results by match score

[adamtheturtle]

Follow-up to #3369 / #3385.

#3385 makes the mock's query result order deterministic, by sorting matches by upload_date and then target_id. That fixes the flake, but it is not the real Query API's order: real Vuforia orders results by match score, best first.

Why the mock does not do that yet

ImageMatcher.__call__ returns bool (src/mock_vws/image_matchers.py:21), so there is no score to rank on.

The default StructuralSimilarityMatcher already computes a raw SSIM at src/mock_vws/image_matchers.py:89 and discards it, so the number does exist for the default case. ExactMatcher is genuinely binary.

What would need deciding

• Protocol shape. Does __call__ return float? Or float | None, so that matchers which only have a yes/no answer can say so? Does ImageMatcher become an ImageScorer?
• Backwards compatibility. query_match_checker and duplicate_match_checker are public parameters, so any custom matcher a caller has written returns bool today. Changing the protocol breaks them. See docs/source/versioning-and-api-stability.rst.
• Ties. ExactMatcher and any bool-returning matcher tie every match, so the (upload_date, target_id) ordering from Return targets in a deterministic order #3385 stays as the tiebreak regardless.
• Scope. Does GET /duplicates/{target_id} rank as well, or only the Query API?

What this would and would not buy

It would help callers whose application logic reads "the first result is the best match" — under the default matcher they would get realistic behaviour rather than "first uploaded".

It would not make the mock agree with real Vuforia's order, since Vuforia's scoring is proprietary and the mock does not intend to copy it (see the "Image matching" section of differences-to-vws.rst). So the verify-against-real tests still could not assert a shared order, and the "Result ordering" section added in #3385 would still need a caveat, just a different one.

Note also that the score is not part of the response body — the real Query API returns only target_id and target_data per result — so this is visible purely as ordering.