fix(tests): correct stale expected values in Windows-gated unit tests (closes #53, #54)

[githubrobbi]

Both tests were surfaced by PR #52's preview lane (run 24873800282 on 2026-04-24) as "Windows portability" failures. Investigation revealed that neither is actually platform-dependent — both are just stale hardcoded expected values that had NEVER EXECUTED IN CI before the preview lane ran them for the first time.

Closes #53.
Closes #54.

Root cause (common to both)

Each test is inside a #[cfg(windows)] gate (module-level for pipe.rs, mod pipelined; declaration for pipelined.rs). In the current CI setup:

• pr-fast.yml Tests job runs on ubuntu-22.04 → the gated modules are excluded → tests aren't compiled or executed.
• pr-fast.yml Windows compile check → only runs cargo check --target x86_64-pc-windows-msvc → modules compile but tests don't execute.
• preview-artifacts.yml smoke-windows (first ran 2026-04-24) → first CI location that ever executed these tests on Windows.

Result: hardcoded expected values drifted from reality over the lifetime of the codebase without anyone noticing, because the assertions were dead code.

Bug #5 — uffs-security::pipe::tests::fnv1a_known_vector

- assert_eq!(fnv1a_64(b"foobar"), 0x8584_8993_3606_5430);
+ assert_eq!(fnv1a_64(b"foobar"), 0x8594_4171_F739_67E8);

The new value is the canonical FNV-1a-64 of "foobar" per the reference implementation. Cross-checked with a pure-Python implementation using the same OFFSET = 0xCBF29CE484222325 / PRIME = 0x100000001B3 constants as the Rust impl.

The old value was just wrong from the start. Not a platform dependency — the original #53 issue's endianness / encoding theories are withdrawn.

Bug #6 — uffs-mft::io::readers::pipelined::tests::test_pipelined_reader_creation

- assert_eq!(reader.chunk_size, 64 * 1024);
+ assert_eq!(reader.chunk_size, DriveType::Ssd.optimal_chunk_size());

Plus analogous for Hdd and Unknown. optimal_chunk_size() returns 2 MiB / 1 MiB / 1 MiB respectively. The old hardcoded 64 * 1024 was a stale prototype value, never updated when the chunk-size tuning was revised.

Deriving the expected value from optimal_chunk_size() itself eliminates the drift vector: future tuning changes can't silently re-break this test.

Not a Windows vs Linux allocation-granularity thing — the original #54 issue's dwAllocationGranularity theory is withdrawn.

Why one PR not two

Both bugs share the exact same root cause (Windows-gated tests never validated in CI) and have the same mechanical fix shape. Single logical change, single commit, closes both tracking issues. Separate PRs would duplicate the diagnostic narrative without adding value.

Validation plan

Once PR Fast CI goes green, this PR will be labeled preview-binaries to re-bake the preview lane end-to-end. Expected outcome:

• smoke-windows: 1322/1322 tests pass (up from 1320/1322 on PR fix(preview): move build-test-archive to windows-latest; reconcile plan doc #52)
• manifest job: emits manifest.json for the first time (previously blocked by smoke-windows failure via needs: coupling)

After this PR merges, the Phase 5 wrap-up docs-only PR will swap the out-of-band sha256 evidence in §10.3 for the real manifest.json and close the §10.6 Phase 5 wrap-up item.

Lesson (captured in §10.5)

Any test gated behind a platform cfg that is NOT exercised by pr-fast.yml is effectively dead code. The Phase 5 preview lane is currently the only CI location that ever exercises #[cfg(windows)] test bodies. Follow-up idea for a future phase: periodic scheduled job that runs full cross-platform nextest on main (not gated by fast-CI budget) to catch drift proactively in test bodies that the PR lane can't afford to run.