Flaky: service clock baseline test fails when its file runs (same-millisecond createdAt vs anchorSetAt)

[ericgriffin]

Describe the bug
test/features/equipment/presentation/providers/service_clock_baseline_test.dart, test "deleting the service that took over hands the clock back to the baseline", fails when its whole file runs and passes when run alone.

Expected: not DateTime:<2025-09-18 00:00:00.000>
  Actual: DateTime:<2025-09-18 00:00:00.000>
test/features/equipment/presentation/providers/service_clock_baseline_test.dart 162:5

To Reproduce

1. flutter test test/features/equipment/presentation/providers/service_clock_baseline_test.dart fails (seen in a full-suite run and a whole-file run on 2026-09-18).
2. flutter test test/features/equipment/presentation/providers/service_clock_baseline_test.dart --plain-name "hands the clock back" passes three runs out of three.

Seen on a branch that touches no equipment or service code (PR #2087); main's CI was green on the same base commit the day before.

Expected behavior
The test passes regardless of which tests run before it.

Likely cause
baselineInEffect in lib/features/equipment/domain/services/service_due_engine.dart lets a service record take over from the baseline only when the record's createdAt is strictly after the schedule's anchorSetAt. The test sets the baseline and then adds the record back to back. ServiceRecordRepository stamps createdAt from the wall clock, so when both writes land in the same millisecond the record does not count as newer and the baseline stays in effect. The earlier tests in the file warm the database and caches, which makes the same-millisecond case likely.

Possible fixes

• In the test, make the record's creation strictly later than the baseline's set time (an injected clock, or a short delay between the two writes).
• Or decide whether a record created in the same millisecond as the baseline should take over, and compare with !isBefore in the rule if so.