EventListenerTest.OnFileOperationTest fails on Apple Silicon (regression of #7133)

EventListenerTest.OnFileOperationTest fails every time I run it on an M-series Mac. Same assertion at db/listener_test.cc:1382, five times per run.

$ ./listener_test --gtest_filter=EventListenerTest.OnFileOperationTest
[ RUN      ] EventListenerTest.OnFileOperationTest
db/listener_test.cc:1382: Failure
Expected: (info.duration.count()) > (0), actual: 0 vs 0
db/listener_test.cc:1382: Failure
Expected: (info.duration.count()) > (0), actual: 0 vs 0
db/listener_test.cc:1382: Failure
Expected: (info.duration.count()) > (0), actual: 0 vs 0
db/listener_test.cc:1382: Failure
Expected: (info.duration.count()) > (0), actual: 0 vs 0
db/listener_test.cc:1382: Failure
Expected: (info.duration.count()) > (0), actual: 0 vs 0
[  FAILED  ] EventListenerTest.OnFileOperationTest (152 ms)

macOS on arm64, Apple Clang, current main, built with make check DISABLE_WARNING_AS_ERROR=1.

This looks like #7133 coming back. That one was fixed by #7153, which switched FileOperationInfo::TimePoint to steady_clock.

In #7133 @mrambacher pointed out that flush is a no-op on POSIX, so it does basically nothing. steady_clock had enough resolution to catch that on older hardware, but on Apple Silicon the start and finish timestamps come out identical and the duration is exactly 0 ns.

So I don't think this is really about which clock — it's that ReportDuration assumes every file operation takes measurable time. Also worth noting the original was intermittent; this fails on every run.

Would you rather see the assertion relaxed to >= 0, or ReportDuration skipped for operations that can be no-ops? Or something else? Happy to send a PR once I know which way you'd want it.