In your screenshot the "Read-only" checkbox is indeterminate because the graphical dialog never sets this attribute on directories, only on files (as the read-only flag has no effect on directories anyway and is repurposed for something else instead), so the dialog pretends that directories can't even be queried for its state. Either way, even if the files inside had this flag, it would only deny 'write' access but wouldn't stop you from opening the file for reading.

WSL2 runs as a VM guest and its access to /mnt/c is only through a filesystem proxy, which runs under your own Windows account and only has the same access as you do – no matter which Linux user does the access. The inability for WSL2 to bypass Windows access controls is intentional (even more so because the entire WSL2 VM is under your control, as that would otherwise turn it into a trivial security bypass).

The file permissions shown for /mnt/c in WSL are meaningless; there's no translation done from NTFS ACLs to Linux ACLs. (It would be a very lossy translation due to several mismatching semantics, anyway – even if you had used getfacl instead of ls -l, some things like inheritance or the 10+ fine-grained permissions cannot be expressed through "POSIX draft ACLs" that Linux implements. Some Unix-like systems implement NFSv4 ACLs which are 95% the same as Windows, but Linux unfortunately does not.)