Date filter with no end date matches nothing when a timestamp index exists #371

When a search query's time_range has a start date but no stop_date, date_range_from_datetime_range (searchlang.py:669) produces a DateRange with end=None. The two paths in TextRangesInDateRangeSelector.eval (query.py:793) read that differently:

• With a timestamp index (always present in practice): timestamp_index.lookup_range treats end=None as a point query. Both backends do this: get_in_range in storage/memory/timestamp_index.py and lookup_range in storage/sqlite/timestamp_index.py. Only messages stamped at exactly start match. For a bare date, start is midnight, so almost nothing does.
• Without an index, get_text_range_for_date_range uses DateRange.__contains__, where end=None means start <= t, i.e. open-ended.

The TypeScript original treats a missing end as open-ended in the index too: getInRange returns values.slice(startIndex) when stopAt is undefined.

Repro

Four messages stamped 2024-03-04 09:00, 2024-03-05 09:00, 2024-03-05 15:30 and 2024-03-07 08:00. The time range is DateTimeRange(start_date=DateTime(date=DateVal(day=5, month=3, year=2024))).

DateRange: DateRange(datetime.datetime(2024, 3, 5, 0, 0, tzinfo=datetime.timezone.utc))
with timestamp index (query.py:804):   messages []
without index (query.py:810):          range TextRange(TextLocation(1, 0), TextLocation(4, 0))

The schema tells the LLM to use time_range for "a particular year, month etc.", so start-only ranges are a normal output. With an index, those queries silently return no results.

Expected

Both paths agree. Since DateRange.__contains__ and TypeScript both read end=None as open-ended, the index lookups should too. Whether a start-only bare date should instead mean that whole day is a separate question for date_range_from_datetime_range.