[Inference1]

Which issue or RFC does this PR close?

Refs #2075 — this does not close it; #2079 is the implementation and already claims it.

Rationale for this change

#2075 measured that a single prepare_context issued one authority read per candidate. #2060 and
#2079 remove that amplification, and #2079's own description states "No SQL-count assertions added".

Nothing in the suite pins the result, so the consolidation can silently regress: the failure mode is
one extra statement per candidate, which is invisible to content, token-statistics, and authorization
tests. This adds the missing guard, in the same style as the existing budget test for the statistics
selection path ("A selection must not cost one query per Scope; see issue #1599",
tests/builtin/runtime/test_statistics.py:553), which uses the same before_cursor_execute counter
harness.

What changes are included in this PR?

One appended test in tests/builtin/runtime/test_statistics.py, no production changes:

• Count every statement issued by one prepare_context on the default text-recall path (in-memory
  SQLite, no embedding model, no reranker), for 8 and 40 Atomic Memories in one Scope.
• Assert the two counts are equal: past candidate-pool saturation, a larger corpus must not cost more
  reads.
• Assert the count stays at or below a pinned ceiling.

The ceiling is 48, which is the value measured on current master plus one statement of slack. It is
deliberately not tighter so this PR lands green on master today and stays green when #2079 merges
(which lowers the observed value to 16). Once #2079 is in, the ceiling can be tightened — happy to do
that in a follow-up commit here, or leave it to a separate change, whichever reviewers prefer.

Are there any user-facing changes?

No. Test-only: no production module, no contract, no schema, no configuration change.

How was this change tested?

The same test file was run unchanged against three source trees, which is what makes it a guard rather
than a tautology:

tree	counted(8) vs counted(40)	result
b388a18 (the revision #2075 measured)	130 vs 178	fails on assert pool == beyond
e4efb39b (current master, this PR's base)	47 vs 47	passes
91293e5 (#2079 head)	16 vs 16	passes

So it rejects the pre-#2060 behaviour and accepts both the current baseline and #2079's consolidation —
it composes with that PR instead of competing with it.

• pytest tests/builtin/runtime/test_statistics.py on master: 10 passed.
• ruff check and ruff format --check with the locked ruff==0.15.20: clean.
• Not evaluated: MySQL/OceanBase and seekdb backends, the reranker-on path, mode="vector", and
  multi-Scope prepare. The ceiling is therefore a SQLite-path number; on another backend the
  statement count should be identical (it is the same code path) but this PR does not claim to have
  measured it.

[hireview001]

LGTM

[hidb4ai]

LGTM