Filter history: order list integration

[AdamGrzybkowski]

Part of WOOMOB-3326 — WOOMOB-3826

Description

Third PR in the filter history stack: wires the shared history screen (#16421) into the order list filters. Behind the FILTER_HISTORY flag.

• Adds a flag-gated clock entry point to the order filter screen → opens the history screen with source=orders and tracks filter_history_button_tapped.
• Saves the current selection to history when the user taps Show Orders — from either the categories screen or an options sub-screen — via a new SaveOrderFilterToHistory use case that reads the full selection from OrderFiltersRepository (the source of truth) and runs fire-and-forget on the app scope, so navigation isn't blocked and a rare failure can't crash the app.
• Applies a picked past filter by writing the decoded selection (per category + custom date range) back to the repository and rebuilding the categories, reusing the existing persistence→UI round-trip (so filters whose values no longer exist are silently dropped).
• OrderFilterHistoryMapper produces a canonical JSON payload (stable dedup) and a readable label.

Test Steps

Enable Filter History in the developer feature-flag screen, then on the Orders tab:

• Open Filters → tap the clock (top right) → confirm the history is empty.
• Select some filters → Show Orders → reopen the history → the filter appears at the top.
• Apply more filters and confirm newest-first + dedup; swipe to delete one; tap a past filter and confirm the filter screen repopulates and Show Orders lists correctly; Clear History → confirm dialog → empty state.
• Verify Tracks events fire with source=orders.

Stacked PRs

PR 3 of 4. Base branch: issue/WOOMOB-3825-filter-history-screen (#16421).

• I have considered if this change warrants release notes — none needed (behind feature flag, not user-facing).

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce Android by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce Android
	Platform	📱 Mobile
	Flavor	Jalapeno
	Build Type	Debug
	Build Number	778
	Version	25.4-rc-1
	Application ID	com.woocommerce.android.prealpha
	Commit	18e4762
	Installation URL	5j0lm9l7tk9p8

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[claude]

AI Code Review - Found 1 potential issue

The feature is well structured: the shared FilterHistoryRepository/FilterHistoryViewModel are reused cleanly, the payload encoding is canonicalized for reliable dedup, the save runs fire-and-forget on the app scope with failures swallowed, and the test coverage (mapper round-trip, save use case, both ViewModels) is thorough. One correctness issue on the custom-date-range round-trip is called out inline.

PR housekeeping

• Applied repo AGENTS.md/CLAUDE.md guidance: store-app MVVM patterns (ScopedViewModel, triggerEvent/MultiLiveEvent, repository-mediated data access) are followed correctly.

---

_{Automatic review · claude-opus-4-8 · Workflow run}

_{How to reply to a finding}

Reply on this review (or inline at the line the finding refers to) with one of:

• @claude addressed - I made the change. Bot verifies against the next diff before marking resolved.
• @claude rejected: <reason> - Will not fix; reason gets quoted on the next review.
• @claude not-applicable - Finding does not apply (wrong file, already covered elsewhere, etc.).

The bot honours these on the next review pass.

[claude]

AI Code Review [fix here]

Issue: Custom date range is saved in the wrong unit. getCustomDateRangeFilter() returns the range converted to milliseconds (startDay.toDateAtStartOfDay().time), and that value is stored in the payload as customDateRangeStart/customDateRangeEnd. On restore, OrderFilterCategoriesViewModel.onPastFilterSelected() passes those numbers straight into orderFilterRepository.setCustomDateRange(...), which expects epoch days (same contract as the picker: OrderFilterOptionsViewModel.onCustomDateRangeChanged(startDay, endDay) → setCustomDateRange). Applying a saved filter that has a custom date range therefore writes a millis value into the days pref, yielding a corrupted, far-future range. The existing tests don't catch this because both sides are mocked.

Suggestion: Store epoch days in the payload so the round-trip matches setCustomDateRange. Use getCustomDateRangeDays() instead of getCustomDateRangeFilter() here:

val customDateRange = orderFiltersRepository.getCustomDateRangeDays()

Consider adding a round-trip test that goes through the real OrderFiltersRepository (not a mock) to lock the units down.