Return real handle metadata from Windows fstat

Windows `fstat` obtains only the file size, then reports a regular-file mode and `mtime = 0` for every successful call. The adjacent path-based `stat` reads actual attributes and last-write time. Querying the same ordinary file through a path and an open handle can therefore report different modification times, even without a concurrent change.

Source evidence at the head of #520:

- [std/sys/windows/fs.wave:219](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/sys/windows/fs.wave#L219) — `pub fun fstat`
- [std/sys/windows/fs.wave:229](https://github.com/wavefnd/Wave/blob/2ae0a91c57fd76323124c0e4dff552adbfadbe1b/std/sys/windows/fs.wave#L229) — `pub fun stat`

Acceptance:

- [ ] Populate size, type and modification time from native handle metadata, with the same units as path-based stat.
- [ ] Compare stat/fstat for a nonempty temporary file with a known nonzero timestamp.
- [ ] Handle directory and non-file handles explicitly; never fabricate regular-file metadata when unsupported.
- [ ] Add native amd64 and ARM64 coverage without libc FFI.

Related: #385. Error translation is a separate concern from filling successful metadata.

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 in std/sys/windows/fs.wave at the pub fun fstat and pub fun stat entries linked in the issue, then inspect the existing native Windows handle and path metadata calls. Compare both functions on a nonempty temporary file with a known nonzero timestamp, and cover directory or unsupported handles on amd64 and ARM64 without libc FFI. Done means size, type, and modification time agree where supported and unsupported handles are not reported as regular files.

Written by the indexing model from the issue text.