Top-k fast path compares numeric thresholds by a truncated key #2071

filter_subjects_by_numeric_gt in fluree-db-query/src/fast_star_const_order_topk.rs uses two encoded-key comparisons in place of a numeric value comparison, and both drop rows the spec keeps. It's the class #2010 fixes elsewhere (comparing by encoding rather than by value), but it's a fused fast path's own filter, so it isn't on #2010's surface. It's wrong results on main.

• A double threshold is truncated toward zero. It becomes (*d as i64, *d), and integer rows compare o_key > encode_i64(thr_i). So > -2.5 becomes > -2 for integers and drops -2, and > -0.5 becomes > 0 and drops 0. A saturating floor() fixes the integer side. (SPARQL negative literals only dodge this because they lower to unary minus, which the detector doesn't take as a constant; JSON-LD's > -2.5 hits it.)
• Only XSD_INTEGER and XSD_DOUBLE rows are compared. Every other numeric o_type (xsd:int, xsd:float, xsd:decimal, NUM_BIG integers beyond i64, the other XSD integer types) falls to _ => false and is dropped, so FILTER(?v > 0) over rows typed int, float, decimal or a big integer returns nothing. On meeting any of those, the lane should decline to the operator's existing fallback rather than answer false.

#2044 edits this same function (its NaN guard and all_integers) and adds threshold_key_interval in fast_count.rs, so this lands cleanest on top of #2044, with integer and double rows going through that shared interval.

For tests, I'd want MustFire / MustNotFire stamps on the same ledger, a fixture holding int, float, decimal and big-integer values, thresholds -2.5, -0.5 and 0, SPARQL and JSON-LD twins, and the fast-paths-off differential checked against hand-written answers, since a bug in a plan both lanes share is invisible to the differential alone.

Found while reviewing #2010.