Flaky unit test: query.test.js sorting read-count assertion fails (masked by ERR_INVALID_ARG_TYPE)

## Summary
`unitTests/resources/query.test.js` → "Querying through Resource API > Sorting > Query data in a table with narrow constraint sorting on different property" intermittently fails. In the failing job the test **passed on the first suite pass and failed on the second pass within the same job**, confirming nondeterminism. Re-running goes green.

## Exact error
```
TypeError [ERR_INVALID_ARG_TYPE]: The "message" argument must be one of type string or function. Received undefined
at innerFail (node:internal/assert/utils:135:11)
at assert (node:assert:186:3)
at Context. (unitTests/resources/query.test.js:905:4)
```
Line 905 is a bare `assert(QueryTable.primaryStore.readCount - start_count < 25)` (no message arg). The `ERR_INVALID_ARG_TYPE` is a masking artifact of the bare `assert()` failing — the real failure is the **read-count efficiency assertion** (the sorted, narrow-constraint query read more rows than the `< 25` budget allows), which is sensitive to cache/index warm-state and load.

## Why it's a flake
The assertion is a performance / read-count heuristic, not a correctness check; it depends on store warm-state that varies under CI contention. Same commit passes on re-run and even passed earlier in the same job.

## Suggested fix direction
- Give the `assert` a message so future failures are legible, and/or make the read-count budget tolerant of cold-cache runs (or assert behavior / result-order instead of read count).

## Affected job / runtime
`Unit Test (Node.js v26)` (mechanism not runtime-specific).

## Evidence
- PR #1371 run 27734341234 / job 82047879165 (attempt 1; attempt 2 green) — passes on first suite pass (~log line 7953), fails on second pass (~9881).

---
_Filed by Claude (Opus 4.8) during CI flake triage while shepherding #1363/#1371/#1374._

Start in unitTests/resources/query.test.js at line 905 and run the "Querying through Resource API > Sorting > Query data in a table with narrow constraint sorting on different property" test, including repeated runs. Inspect the read-count assertion and its surrounding setup; done means failures are legible and the test no longer flakes under repeated or cold-cache runs while preserving the query result checks.

Written by the indexing model from the issue text.