Unit tests for ScenarioRuleEngine evaluate() algorithm

Structure the test file as: (1) imports and fixture declarations at the top, (2) setUp() building a fresh ScenarioRuleEngine with mock dependencies for each test, (3) test groups in dependency order matching the condition evaluation chain. For boundary value testing, consider a parameterized helper: void runBoundaryTest(int duration, int min, int max, bool expectMatch) — this prevents copy-paste drift when the boundary logic changes. Extract ActivityMetadataBuilder and ScenarioRuleBuilder factory helpers into test_helpers/scenario_fixtures.dart using the builder pattern (return a base object and allow named parameter overrides) so individual tests only specify the fields relevant to their assertion. Document in a top-of-file comment which tasks are under test and what the coverage target is.

If Mockito is not already a dev dependency, prefer hand-written test doubles over adding a new package dependency — the interfaces are simple enough.

This task IS the testing task. Organize tests using flutter_test's group() and test() functions. Use a TestPromptHistoryRepository (hand-written test double implementing PromptHistoryRepository) that returns configurable last-prompt timestamps. Use a TestClock (hand-written or Mockito mock) injected into ScenarioRuleEngine for deterministic time control.

Apply table-driven tests using a List of test cases for boundary value scenarios to maximize coverage with minimal boilerplate. Include a 'golden path' integration-style test at the bottom of the file that chains task-005 evaluate() and task-006 getPrioritizedMatch() together on a realistic scenario pulled from the HLF peer mentor follow-up use case described in the requirements documentation.