htree lookup misses existing entries whose hash sorts below the first dx entry (dx count/limit overlay used as an entry) — existing files unopenable/undeletable on valid indexed dirs

Summary

Observed on both stock and fixed kernels during DF-3082 verification: rm of payloadname01..50 (present entries, verified on-disk) silently no-oped - lookup returned ENOENT - on an e2fsck-built index whose dx root stores no leading low sentinel. ext2_htree_find_leaf's binary search resolves hashes below the first real entry to found = start-1 = the count/limit overlay entry itself (ext2_htree.c:312-333), so such names are searched in the wrong block and reported absent. Certain behavior (reproducible on both kernels), mechanism attribution by code reading - related to the upstream 'dirents sometimes get lost' XXX at :908-919; full verification belongs to the ext2_htree.c pass. On valid Linux-created indexed directories, names hashing into the low range resolve ENOENT: open/stat/rm of existing files fail; namespace silently diverges between readdir (linear, sees them) and lookup (indexed, misses them). Reproducible with the DF-3082 pack (rm of 50 -> count stays 100). Fix: pin the candidate to the first real dx entry on underflow + linear fallback on leaf miss.