Sixteen matches from an older folder hide a much more frequent suggestion in the current folder

## Problem

Candidate retrieval merges sibling scopes in database order and takes the first 16 distinct texts before ranking. It never globally compares the evidence before truncation. An earlier scope can fill the entire candidate budget, excluding a much stronger candidate in the current scope.

## Evidence

Reviewed `main` at `8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d`. Reproduced against the unchanged production source in an isolated Swift package on macOS, with fake transport or temporary stores as appropriate. These checks assert the observed defect; they are not a claim that the full app test suite passed.

In an in-memory `PredictStore` with the same application and role:

1. In scope `/a`, record `git old-000` through `git old-015` once each.
2. In scope `/z`, record `git status` 100 times, at the same timestamp.
3. Request candidates for `/z` matching `git `.

Observed: the 16 `git old-*` strings are returned; `git status` is absent. Fixed-width numeric suffixes keep this reproduction independent of fragment supersession. Downstream `Ranking` cannot recover a candidate already discarded.

## Relevant code

- [Sources/UttrflowPredictStore/PredictStore.swift:55](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictStore/PredictStore.swift#L55)
- [Sources/UttrflowPredictStore/PredictStore.swift:108](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredictStore/PredictStore.swift#L108)
- [Sources/UttrflowPredict/Ranking.swift:12](https://github.com/uttrflow/uttrflow-swift/blob/8d93f5b8574f3c7b8c30086d9c817bf7f5d4827d/Sources/UttrflowPredict/Ranking.swift#L12)

## Fix and acceptance criteria

Merge and prioritize candidates across all matching scopes before applying the final limit; preserve the intended frequency/recency and scope semantics. Add the 16 low-frequency versus one high-frequency case and verify results do not depend on scope insertion or lexical ordering.

## Existing work checked

#750 concerns uncovered combine/fuzzy branches, not candidate starvation before ranking.

Start in Sources/UttrflowPredictStore/PredictStore.swift at lines 55 and 108, then inspect Sources/UttrflowPredict/Ranking.swift at line 12. Reproduce the /a versus /z scenario with 16 low-frequency candidates and one frequent candidate, then add coverage for insertion and lexical-order independence. Done means matching candidates are globally prioritized before the final limit while frequency, recency, and scope semantics remain intact.

Written by the indexing model from the issue text.