Git check for corrupted files in the working directory

Question

Context

I had a Windows crash (I had to cut the power to the PC) during work and a bunch of files got corrupted (random binary data overwritten on text files, things like this). I noticed this because git didn't recognize the folder as a git repo anymore (at least .git/HEAD and .git/index got corrupted) and some text file inside the working dir got corrupted.

Fortunately everything was pushed to the remote so this isn't about recovering uncommitted changes.

For git itself I recovered it by deleting .git/, git init, remote add and fetch.

The problem

Because of the crash I felt I couldn't trust git status to know if there are modifications to the files (i.e. corrupted files). Maybe Windows corrupted files without git knowing about it. Maybe files got corrupted at a hardware level during the power shutdown (e.g. files being written from cache, ssd reorganizing data internally during the forced power shutdown).

I did git fsk and git lfs fsck but from the documentation it seems to me this checks that the internal structure of the git repo is valid (i.e. ./.git/**).

The question

Is there a way for git to check every file in the repository comparing it bit by bit with the index to detect modifications? I suppose hash comparison would also be ok. Or maybe am I wrong and git status already does that (my assumption is that git uses some OS callbacks to get notified when a file is modified).

I ended up deleting everything and cloning it again, but I want to know if there is a better way (as for some repos cloning can take a lot of hours).

---

Using git on Windows (default official install, with lfs files in the repo, from within Windows Terminal, Windows 10)