Inconsistent behavior on Windows from deprecated st_ctime_ns stat

[sneakers-the-rat]

didn't know this was yours as well!

Noticed that only the windows tests were failing here for a circumstance where a cache should have been invalidated because the creation time, but not the mtime was changed: dandi/dandi-cli#1364

i think this comes from here: https://github.com/con/fscacher/blob/e3a6dee365f89a3b0212d19976e61a8165bf0488/src/fscacher/cache.py#L209C10-L209C10

where a fingerprint is generated for a file using s.st_mtime_ns, s.st_ctime_ns, s.st_size, s.st_ino

st_ctime_ns is deprecated on windows:

In 3.12:

Changed in version 3.12: st_ctime_ns is deprecated on Windows. Use st_birthtime_ns for the file creation time. In the future, st_ctime will contain the time of the most recent metadata change, as for other platforms.

In 3.11:

Platform dependent:
the time of most recent metadata change on Unix,
the time of creation on Windows, expressed in nanoseconds as an integer.

It's not clear to me how one would reconcile them since the 'get last metadata change' behavior isn't available in windows, but the docs say it should be 'in the future.'

In the meantime it might be good to add a small ~1kb hash from the front and back of a file or something in the fingerprint.

mostly raising the issue to bring it to attention, doesn't seem like an urgent problem, but seems good to note when OS inconsistencies arise.