pin the emptied-leaflet and NumBig-gate check ordering

[aaj3f]

Test-only. #1624 lets a rebuild leave emptied leaflets behind, and #1628 added a gate that declines the whole-graph COUNT(DISTINCT ?o) fast path when a leaflet's key range covers OType::NUM_BIG_OVERFLOW. Those two compose only because the directory walk skips an entry on row_count == 0 || lead_group_count == 0 before it consults leaflet_may_hold_non_identifying_o_key — bplatz checked that by reading during #1628's review, and this pins it by execution instead.

It is not a no-op confirmation. Reordering the two checks turns this test red, which means the emptied leaflets really do still carry key ranges spanning the NumBig o_type — so a gate consulted first would decline whole-graph COUNT(DISTINCT ?o) permanently on any ledger that has ever held a decimal. Nothing else in the file would catch that, since every other case runs on a freshly imported ledger with nothing retracted.

The shape is decline-then-proceed across a retract-and-reindex cycle: seed six distinct objects of which two are decimals, index, assert the gate declines and the general pipeline answers 6; retract both decimals, reindex, assert the answer is 4 and distinct object COUNT proceeds again. The first half doubles as the lane probe, so the second half can't pass vacuously on a ledger that never made it onto the indexed lane.

Related: the exact NumBig-aware counter that would restore the fast path for decimal-bearing ledgers is tracked separately in #1638; this PR only pins the ordering the current gate depends on.

[bplatz]

This looks like it's no longer needed — #1644 (merged 2026-08-20, after this branch's last commit) redesigned the exact code path this PR pins.

For context: this PR pins the check ordering in the directory walk this test exercises — entry.row_count == 0 || entry.lead_group_count == 0 short-circuiting before leaflet_may_hold_non_identifying_o_key is consulted — so an emptied leaflet from a retract-and-reindex cycle (#1624) doesn't get mistaken for one that might still hold a NumBig object. That was true against #1628's gate, which declined the whole-graph COUNT(DISTINCT ?o) fast path outright whenever the graph held any NumBig object.

#1644 replaced that decline-outright behavior with an exact NumBig counter that runs alongside the plain object count (fluree-db-query/src/fast_count.rs, the walk_lead_groups/count_distinct_objects machinery, NUMBIG_EXACT_SITE). I merged current main into this branch to check, and:

• The merge conflicts on it_distinct_object_numbig_gate.rs, because main already carries a different Phase 4 (the rollout-cap test) from count the NumBig distinct-object slice exactly instead of declining #1644.
• With both phases kept, this PR's own composition test fails against current main. Its "before" assertion requires the plain distinct object COUNT site to not fire when NumBig is present — but under count the NumBig distinct-object slice exactly instead of declining #1644 it now fires alongside distinct object COUNT (numbig exact), which is the new design working as intended, not a regression.
• I also swapped the check order this PR is meant to protect and reran the full test file — output was byte-identical, including the phases that came from count the NumBig distinct-object slice exactly instead of declining #1644. On the fixtures this test file exercises, that ordering no longer has any observable effect on current main.

So the specific composition risk this PR guards against looks like it's already covered by whatever test discipline landed with #1644, and the emptied-leaflet interaction this PR is about doesn't currently distinguish correct from swapped ordering anymore.

If there's a scenario #1644's own tests don't reach where the ordering still matters, happy to be pointed at it — otherwise this looks safe to close in favor of #1644's coverage.