feat: add start_date/end_date time filter support for search job

[xyf2020]

• Add _extract_date_from_path to extract validated YYYY-MM-DD from chunk paths
• Add start_date/end_date filtering in _matches_search_filter
• Implement progressive recall in FaissLocalFileStore.vector_search
• Promote start_date/end_date from context to search_filter in SearchStep
• Add start_date/end_date parameters to search job in default.yaml
• Add unit tests for date filter functionality

[jinliyl]

Thanks for the PR. I checked the changes locally and ran the related/unit tests:

• python -m pytest tests/unit/test_file_store_consistency.py tests/unit/test_search_step.py passed
• python -m pytest tests/unit passed

The no-date path looks backward compatible in normal usage: when start_date and end_date are not provided, SearchStep does not add them to search_filter, LocalFileStore skips the date filter, and FAISS still uses the previous no-filter over-fetch path.

A couple of points would be good to tighten before merging:

1. Please validate/normalize start_date and end_date before comparing them.

   Right now _matches_search_filter compares the raw filter values as strings. If a caller passes an invalid or non-normalized date such as 2026-2-28 or abc, the lexicographic comparison can produce incorrect results. For example, an invalid end_date may keep dates that should be excluded, and an invalid start_date may exclude all dated paths.

   We already have strict date helpers such as parse_daily_date; it would be better to reject invalid values in SearchStep with a clear error, or normalize them before they reach the file store.

2. Please clarify the intended behavior for paths without an embedded date.

   Currently, when a date filter is provided, paths where _extract_date_from_path returns None are still retained, e.g. digest/personal/topic.md. This may be intentional because digest/ contains long-term memory, but it should be documented or explicitly tested as part of the expected semantics. If the intended meaning is “only return results within this time range”, then no-date paths should probably be excluded when a date filter is active.

3. Minor robustness suggestion: _extract_date_from_path currently uses parts[1].split(".")[0], so a second path segment like 2026-05-18.anything would be accepted as 2026-05-18. It may be safer to only accept either an exact YYYY-MM-DD segment or the day-index form YYYY-MM-DD.md.

Overall the implementation direction looks reasonable, especially the progressive FAISS recall. I think the main thing to address is date input validation and making the no-date-path semantics explicit.

[CLAassistant]

All committers have signed the CLA.

[jinliyl]

LGTM

[ployts]

LGTM