Backport FastIoQueryNetworkOpenInfo fast path for NtQueryFullAttributesFile

## Context

`NtQueryFullAttributesFile` is a post-NT-3.5 API (it does not exist in the 3.5 base) forward-ported from srv03 to back `GetFileAttributesEx` / Python `os.stat` (size + timestamps + attributes in one call).

## Current implementation (synthesis)

The `QueryOnly` branch in `NTOS/IO/PARSE.C` synthesizes `FILE_NETWORK_OPEN_INFORMATION` from two classes the 3.5 filesystems already support:

- `FileBasicInformation` → timestamps + attributes
- `FileStandardInformation` → `AllocationSize` / `EndOfFile`

This goes through the slow path (`IopCreateRealFileObject` + two `IoQueryFileInformation` calls). It is correct and touches no FS driver.

## The open problem

NT 4.0+ added a `FastIoQueryNetworkOpenInfo` entry to `FAST_IO_DISPATCH`, which returns the whole `FILE_NETWORK_OPEN_INFORMATION` directly from the cached FCB — no IRP, no real file-object allocation. This is the fast path that makes `os.stat`-heavy workloads cheap.

MicroNT's 3.5 filesystems do not implement it:

- `FAST_IO_DISPATCH` lacks the slot (gated by `SizeOfFastIoDispatch`).
- Neither `NTOS/NTFS` nor `NTOS/FASTFAT` has a handler (`grep FastIoQueryNetworkOpenInfo` is empty tree-wide).

## What backporting requires

1. Extend `FAST_IO_DISPATCH` + bump `SizeOfFastIoDispatch` (versioned struct).
2. Implement `FastIoQueryNetworkOpenInfo` in **both** NTFS and FASTFAT, pulling size/times/attrs from the FCB.
3. Use it in the `PARSE.C` `QueryOnly` branch ahead of the synthesis fallback.

## When to pick this up

Only if stat-heavy workloads show measurable cost. The synthesis path is correct and the slow path must exist anyway (fast I/O is always optional), so this is a pure performance optimization — not a correctness gap.