Constant MAX_LIMIT_AS_FAILSAFE 

pub const MAX_LIMIT_AS_FAILSAFE: u32 = 1024;

Hard cap on entries the count fan-out arms ask the executor to return.

Count fan-out (PerInValue, and the Aggregate + range sub-case of RangeNoProof) emits at most one entry per In value, and In is structurally capped at 100 by super::conditions::WhereClause::in_values. This cap sits well above the real bound. Two reasons to pin it explicitly instead of leaning on the operator-tunable default_query_limit:

1. default_query_limit is a documents-fetch knob — applying it to count fan-out can truncate aggregate sums below |In| under tighter operator tuning, silently producing wrong totals.
2. Pinning a number here keeps the dispatcher’s correctness independent of operator configuration.

1024 is high enough that the cap never fires under the current WhereClause::in_values policy. If a future code change makes it reachable, treat that as a signal to revisit the bound before raising the constant.

Pattern: failsafe cap for structurally-bounded ops

This is the prototype of a small project convention: when an executor-level operation has a structural upper bound enforced upstream (here, WhereClause::in_values()’s 100-cap on the In array), pin a failsafe cap at the executor boundary that sits well above the upstream bound rather than reusing an unrelated operator-tunable limit. The failsafe never fires under the upstream constraint — it exists to (a) keep behavior independent of operator config, and (b) localize the blast radius if the upstream constraint ever loosens. Constants added under this pattern should follow the MAX_<OPERATION>_AS_FAILSAFE naming so the role is visible at the use site.