fix(index): express comparison bounds in the indexed property's type (#222)

[mrdevrobot]

Fixes #222.

Problem

In r.Count < 9.5 or r.Count >= 5L the compiler wraps the property in Convert(r.Count, Double/Int64). The two Convert branches of IndexOptimizer.ParseSimplePredicate returned the constant with its own type. ConvertToIndexKey then encoded it as a double or long key, compared bytewise against the index's int keys, so the scan covered the wrong range: wrong counts and rows, and an exception for Max.

Fix

Both Convert branches now call TryConvertBound. It expresses the bound in the property's own type, adjusting the operator where needed. Properties with a value converter are left as they were.

int/long properties. Only a widening comparison is planned:

• int→long, int/long→decimal and int→double are exact everywhere;
• long→double is exact below 2^53;
• int/long→float is exact below 2^24.

The bound becomes the integer that selects the same values. < 9.5 becomes <= 9, >= 2.5 becomes >= 3 and > 2.5 becomes >= 3. == 5.5 is always false.

Out-of-range and NaN bounds. An always-true comparison becomes >= MinValue, which keeps the plan exact and still leaves out the nulls of an int?. An always-false one becomes > MaxValue. HasResiduePredicate stays false, so the key-count push-down in CountByPredicateAsync stays correct.

Pairs already keyed alike are kept:

• float/double;
• DateTime/DateTimeOffset;
• numeric bounds on a decimal property, which the decimal-keyed index converts itself;
• integer bounds on a nullable enum, which become the enum value.

Anything else gets no index, and the predicate is evaluated per document. That covers NaN on float/double/decimal properties, narrowing casts such as (int)r.Total == 5, and lossy bounds beyond the exact limit. In an AND, the other side becomes the plan, with a residue.

Beyond the issue. Only Convert/ConvertChecked count as "the property" now. Before, -r.Count > 5 or an ArrayLength over an indexed property could be planned as a key range on that property.

Aggregates. The type guard in TryAggregateAsync (from #183) stays. Converted bounds now pass it, so these filters use the index-key aggregate. Only its comment changed, and one in LinqAggregateTests.

DynamicCollection doesn't use this planner and is not affected.

Tests

IndexBoundConversionTests has 171 tests on AggregateDbContext/Reading (indexed int Count, long Total and int? MaybeCount), with data 0..19 plus documents at the int and long minimum and maximum.

• 56 predicates, each compared with LINQ to Objects through Where().ToListAsync(), CountAsync(pred) and Where().Max/Min (exceptions included). They cover the issue's table plus inclusive and strict bounds, in and out of range, NaN, ±infinity, float and decimal bounds, long and int? properties, AND merges of converted bounds, captured variables, and the reversed form 9.5 > r.Count.
• Plan-shape checks: Count < 9.5 gives an exact plan with max 9 inclusive; Count >= 5L gives an int min of 5; Total > 1e17 gives no plan.

Before the fix 112 of the 171 failed. Full BLite.Tests suite: 2964 passed, 4 skipped, 0 failed. BLite.Core builds with no warnings.

Left as is

• Indexes keyed on a cast, such as CreateIndexAsync(r => (long)r.Units). CollectionIndexInfo doesn't carry the key type, so bounds are still expressed in the property type. Even a plain r.Units == 5 against such an index was already mismatched before this PR.
• A double bound on a decimal property ((double)r.Price >= x) is still converted by the index as before. It can be off by a hair for decimals with more than about 15 significant digits.
• Lossy long→double and int→float bounds beyond 2^53 and 2^24 give up the index rather than computing the exact threshold. This is correct, but slower.

🤖 Generated with Claude Code