fsmonitor: t7527 racy on OSX?

I have access to a Mac OS X M1 box (gcc104 at [1]) where t7527 reliably fails due to what seems to be a race us doing something, and assuming that fsmonitor picked up on it.

This makes the tests pass:
	
	diff --git a/t/t7527-builtin-fsmonitor.sh b/t/t7527-builtin-fsmonitor.sh
	index 56c0dfffea..ce2555d558 100755
	--- a/t/t7527-builtin-fsmonitor.sh
	+++ b/t/t7527-builtin-fsmonitor.sh
	@@ -428,6 +428,7 @@ test_expect_success 'edit some files' '
	 	start_daemon --tf "$PWD/.git/trace" &&
	 
	 	edit_files &&
	+	sleep 1 &&
	 
	 	test-tool fsmonitor-client query --token 0 &&
	 
	@@ -443,6 +444,7 @@ test_expect_success 'create some files' '
	 	start_daemon --tf "$PWD/.git/trace" &&
	 
	 	create_files &&
	+	sleep 1 &&
	 
	 	test-tool fsmonitor-client query --token 0 &&
	 
	@@ -471,6 +473,7 @@ test_expect_success 'rename some files' '
	 	start_daemon --tf "$PWD/.git/trace" &&
	 
	 	rename_files &&
	+	sleep 1 &&
	 
	 	test-tool fsmonitor-client query --token 0 &&
	 
	@@ -978,6 +981,7 @@ test_expect_success !UNICODE_COMPOSITION_SENSITIVE 'Unicode nfc/nfd' '
	 	mkdir test_unicode/nfd/d_${utf8_nfd} &&
	 
	 	git -C test_unicode fsmonitor--daemon stop &&
	+	sleep 1 &&
	 
	 	if test_have_prereq UNICODE_NFC_PRESERVED
	 	then

The failure is when we grep out the events we expect, which aren't there, but if you manually inspect them they're there. I.e. they're just not "in" yet.

I thought this might be a lack of flushing or syncing in our own trace code, but adding an fsync() to trace_write() didn't do the trick.

1. https://cfarm.tetaneutral.net/news/41#