fix(ext/fs): retry without FILE_FLAG_BACKUP_SEMANTICS on Windows when driver rejects it (#34686)

## Summary

Some Windows file system drivers — notably ImDisk-backed memory disks —
reject `FILE_FLAG_BACKUP_SEMANTICS` for regular files and return
`ERROR_INVALID_FUNCTION` (\`os error 1\`).

Deno passes that flag so `CreateFile` can open directories with the same
code path as files, which causes \`Deno.readTextFile\`,
\`Deno.writeTextFile\`,
\`Deno.stat\`, \`Deno.lstat\` (and anything that goes through them, such
as
\`std/fs/exists\`) to fail on those volumes:

\`\`\`txt
Error: Incorrect function. (os error 1): readfile 'y:\a.txt'
Error: Incorrect function. (os error 1): writefile 'y:\test.txt'
Error: Incorrect function. (os error 1): stat 'y:\a.txt'
\`\`\`

This PR transparently retries the open without the flag when we see
`ERROR_INVALID_FUNCTION`. Directories will still fail to open on the
problematic drivers (they need the backup-semantics flag), but on those
drivers only regular-file operations actually need to succeed. Any
other error from the original open still propagates unchanged.

The fallback covers both code paths that explicitly set the flag on
Windows:

- `open_with_checked_path` (used by `read_file_*`, `write_file_*`,
  `open_*`, and the text-file variants that delegate to them).
- `stat` / `lstat` (each open the path with `access_mode(0)` plus the
  flag to grab metadata via `GetFileInformationByHandle` /
  `NtQueryInformationFile`).

## Test plan

- [x] `cargo +1.95.0 check -p deno_fs` (Linux host)
- [x] `cargo +1.95.0 clippy -p deno_fs --no-deps`
- [x] `cargo +1.95.0 fmt --check -p deno_fs`
- [ ] CI Windows job exercises the standard read/write/stat code paths

Hard to add an automated test for the ImDisk-only failure mode here
since we'd need to provision a memory-disk volume on the Windows CI
runner.

Fixes #26257

Closes denoland/divybot#406

Co-authored-by: divybot <divybot@users.noreply.github.com>
Co-authored-by: Divy Srivastava <me@littledivy.com>