Do not report every existing Windows path as accessible for every mode

The Windows `access(path, mode)` implementation ignores `mode` and only checks whether GetFileAttributes succeeds. Consequently R_OK, W_OK, X_OK and invalid mode bits are all treated like F_OK. Callers asking whether an operation is permitted can receive success solely because the path exists.

Source evidence at the head of #520:

- [std/sys/windows/fs.wave:188](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/sys/windows/fs.wave#L188) — `pub fun access`
- [std/sys/windows/fs.wave:52](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/sys/windows/fs.wave#L52) — `pub const FS_X_OK`

Acceptance:

- [ ] Validate mode bits and retain a distinct existence-only F_OK path.
- [ ] Implement the supported permission checks with native APIs; return an explicit unsupported result for a mode whose meaning cannot be supplied reliably.
- [ ] Add fixtures distinguishing existence from denied/read-only write access, and verify invalid mode handling.
- [ ] Do not describe access checks as a race-free substitute for checking the subsequent open operation.

Related: #385. This concerns successful-but-false permission answers, separate from preserving native failure codes.

Audit status: identified by static source inspection; the scenarios above have not been executed during this audit. The permalink fixes the reviewed revision; this report does not claim the defect was introduced by #520.

Start at std/sys/windows/fs.wave, especially pub fun access and FS_X_OK, and inspect the Windows filesystem implementation and its native API usage. Add coverage for existence versus denied or read-only write access and invalid mode bits; done means supported checks are distinguished, unsupported modes return explicitly, and the documentation avoids implying race-free permission checks.

Written by the indexing model from the issue text.