Support searching descending CDX index tags (blocked on a descending fixture)

[chrisrichards]

Context

Split out of #294. That issue's user-facing goal — index-served ORDER BY … DESC — was delivered in #300 by reversing ascending tags. What remains is supporting tags that are themselves created DESCENDING (INDEX ON col TAG t DESCENDING in VFP): QueryPlanner.FindEligibleTags skips them and CdxIndex.Search throws NotSupportedException for them.

Why it is blocked

No fixture in the repository (or seen anywhere in this project's history, including the daiplusplus fork's test data) contains a descending tag, and there are two plausible on-disk designs:

1. Complemented keys: key bytes are stored bit-complemented so the physical B-tree stays byte-ascending, with CdxIndexHeader.Order as a presentation flag (this is how some xBase implementations, e.g. Harbour, handle descending keys). If so: EnumerateEntries walks logical-descending order already, searches need complemented targets, and trailing-trim pad bytes complement too (space 0x20 → 0xDF).
2. Reversed tree: keys stored as-is with descending byte order in the tree, requiring inverted comparisons during interior descent and leaf scanning.

Implementing either on a guess risks silently missing rows — the one failure mode the planner is designed never to accept.

How to unblock

Contribute a small VFP-created DBF + CDX pair containing at least one DESCENDING tag on a character column (ideally with duplicate keys) alongside its data. With that fixture:

• determine the encoding by dumping raw KeyBytes (the same diagnostic approach used to verify the integer key transform in Support integer, numeric, double and date CDX index keys #298);
• implement accordingly in CdxIndex/CdxKeyComparer (+ planner eligibility and CoversWhereExactly exactness rules);
• extend the differential harness (QueryIndexTests/QueryDescendingOrderTests) and add a fixture round-trip test mirroring Fixture_keys_should_round_trip_through_the_integer_transform.

🤖 Generated with Claude Code