Will adding that get it to pass the test? Or will it just cause it to fail instead of throwing a warning?

For some weird reason, Path::Tiny uses flock before reading/writing any file, even though unixish locks are only advisory. But at least this blind checking would prevent multiple programs using Path::Tiny from clobbering each others data.

The documentation also says that you can disable the flocking by setting $ENV{ PERL_PATH_TINY_NO_FLOCK } to a true value.

It will fail early because the pre-condition (flock() works) is not met. It will (should = untested) more clearly point out where the problem is - not in your module, but in the environment. You could wrap the exception and turn it into a more descriptive warning, providing advice on how to fix the test-environment or skip this test.

If the failure is caused by the implementation of the test case, you could fix that, i.e. by circumventing file locking or by skipping the test case (after testing capabilities) with a proper explanation.

If your module requires proper locking, it would be wise to let the test fail, perhaps with a more meaningful explanation. It might even be useful to make the warning fatal in your Anki module, if you cannot find a workaround.
The latter leads to a third option: skip test with warning / fail in production (installed module) if pre-condition is not met. Since your module self-tests the pre-condition, the test case could tolerate a not fully compliant test environment. However, this might break applications that (seemed to) worked fine in the past.

Everything under the assumption that NFS/flock is the real culprit.