fix: honor date range in chat/topic export, skip pre-from history

[Tym-arch]

Summary

Fixes the export-date-range bug reported in #30412 and #25139: selecting a date range in Export chat history causes the client to fetch the entire chat history from the oldest message before producing output. The date range is currently only applied at write time via SkipMessageByDate, so on large channels (millions of msgs) the export appears stuck for hours and consumes massive bandwidth even when the user only wants a few days of msgs.

This PR adds server-side skip-ahead so only msgs in the requested [singlePeerFrom, singlePeerTill) range are ever transferred.

Approach (canonical, GetHistory-based)

1. offsetDate parameter threaded through requestChatMessages → MTPmessages_GetHistory. All call sites updated. Default 0 preserves prior behavior.
2. First-call probe per split in requestMessagesSlice: when largestIdPlusOne == 1 and singlePeerFrom > 0, fires a single getHistory(offset_id=0, offset_date=singlePeerFrom-1, add_offset=-1, limit=1) to find the first msg id at-or-after singlePeerFrom. Sets largestIdPlusOne = result.id and re-enters slice fetching from there. Mirrors the canonical pattern at apiwrap.cpp:3088 (requestMessageAfterDate).
3. Till-stop in slice callback: when slice.list.back().date >= singlePeerTill, sets lastSlice = true to terminate the split early instead of paginating to its end.
4. SingleMessageAfter > date → >= date in export_data_types.cpp — splits whose latest msg date equals singlePeerFrom exactly were being skipped erroneously by the existing pre-iteration filter.
5. Topic path parity — same probe + till-stop in requestTopicReplies / requestTopicMessagesSlice / finishTopicMessagesSlice (the date-range UI surfaces for topic exports too, per export_view_settings.cpp:268-271).
6. Topic loadNextMessageFile SkipMessageByDate added so the file loader respects the date filter on topic msgs.
7. onlyMyMessages Search fallback (kicked-from-channel mid-export) now passes min_date = singlePeerFrom and max_date = (singlePeerTill > 0 ? singlePeerTill - 1 : 0) for correct inclusive-lower / exclusive-upper boundaries matching SkipMessageByDate.

Network savings

Scenario (1M-msg channel, last 7 days)	Before	After
API calls	~10,000 (getHistory per 100-msg batch across all msgs)	~10 (1 probe + ~9 slice fetches for ~1k msgs)

~1000× reduction in request volume for the typical narrow-range case.

Backwards compatibility

• New offsetDate parameter defaults to 0 at every existing call site → unchanged behavior when no date range is set.
• All existing branches (onlyMyMessages Search, CHANNEL_PRIVATE fallback, migrated supergroup splits via negative splitIndex) are preserved.
• No public-API changes outside the export module.

Test plan

• Built with centos_env Docker image (CONFIG=Release, GCC 15) — clean build, 393 MB binary.
• Manually tested: export channel history with date range last 7 days on a busy channel — output produced in seconds, msgs limited to range, file content matches the date filter.
• Manually tested: export with no date range — unchanged behavior.

Fixes #30412
Fixes #25139

[CLAassistant]

All committers have signed the CLA.

[23rd]

Two issues I hit while testing:

1. Progress UI is now inaccurate. Totals are still computed over the full chat range, so with a date range the progress bar shows stale/wrong numbers. Either rebase the progress against the narrowed range, or hide the indicator when a date range is set — current behavior is worse than no progress at all.

2. Regression: export hangs across a basic-group -> supergroup migration. Reproducible: pick a migrated chat, choose a date range that spans the migration boundary. Export hangs indefinitely.

[23rd]

Suggested change

- Honor date range when exporting chat history (no full scan).

[LoZack19]

Hi everyone, just wanted to express my strong support for this PR. As someone who frequently exports chat data for analysis, the current behavior (scanning the entire history regardless of the selected time window) is a major bottleneck for large, long-standing chats.

This optimization would be a massive quality-of-life improvement and save a lot of time. Thank you to the author for the great work on this! Is there anything the community can do to help get this reviewed and merged?