There are some bleve goroutines left running, but OTOH TestSweetEndToEnd seems to run all of the actual tests as subprocess, and there is definitely at least one subprocess still running at the time of the timeout too. I think those goroutines might be a red herring, although they may point to a dependency init issue elsewhere in the package.
I suspect that the timeout is due to a subprocess (compare #50436):
Since it's sweet get, that most likely points to a network flake of some kind. Any suggestions on how I can make this test more resilient to those?
Mainly, plumb through Contexts everywhere, so that if things are broken you can have the subprocess dump useful errors before the text is terminated.
You can use (*testing.T).Deadline to get the test's deadline, and then subtract off some amount of headroom (for starting, communicating with, and cleaning up the subprocess). Then you can plumb in the resulting duration as a flag.Duration for a -timeout flag. (#50436 plus signal.NotifyContext would get you most of the way to using signals instead of flags, but signals aren't really viable on Windows anyway. 🤷♂️)