feat(mft): extended $SI fields, parse status, and macOS target-cpu fix

[githubrobbi]

Three threads, all traced from one request: expose the remaining NTFS 3.0+ $STANDARD_INFORMATION fields at the parse layer.

1. $SI parse layer (the original request)

• ExtendedStandardInfo gains quota_charged, max_versions, version_number, class_id, populated in the NTFS 3.0+ branch of parse_standard_info_full. The NTFS 1.2 branch is untouched — that layout has no such fields and ..from_attributes(…) correctly leaves them zero.
  Costs nothing persistent: ExtendedStandardInfo is a stack temporary in both production parsers, and the 56-byte StandardInfo that lands in MftIndex is unchanged. No index, cache, or on-disk format change.

• StdInfoParse (V30 / V12 / Malformed / Absent), returned by parse_standard_info_full and surfaced on ParsedRecord::std_info_parse.
  Previously a $SI that could not be decoded returned silently, leaving every timestamp at 0 — FILETIME 1601-01-01, a value a real record can legitimately hold. Nothing recorded the failure, so a consumer building a forensic record could only report the default as fact. is_corrupt does not cover this: it is set solely on fixup/USA failure.
  Measured: ParsedRecord stays at 256 bytes (the field lands in existing padding), StdInfoParse is 1 byte in a register, and the variant is just which branch the parser already took. Deliberately not #[must_use] — the bulk pipelines have nowhere to record it and dropping it there is correct, so the value is dead and optimised out.

• Fragment-parser bug fixed. parse_record_to_fragment hand-rolled its own $SI read and unconditionally parsed the 36-byte NTFS 1.2 layout regardless of the attribute's real size, silently zeroing usn/security_id/owner_id on every modern volume. Now routed through the shared, fuzz-hardened helper, so all four parsers agree. Latent today (the function is #[deprecated] with no workspace callers) but kept for a planned carving consumer — see Decide whether to remove the deprecated fragment parser (parse_record_to_fragment) #572.

• Test coverage pins the fields on the public API (parse_record_full), not just the helper: a refactor giving full.rs its own $SI read would otherwise keep helper-level tests green while zeroing the fields for every external caller. Verified to fail when that second hop is broken. New pins also cover all three Malformed conditions, and — the point of the exercise — that a genuine all-zero $SI returns V30 while an undecodable one returns Malformed with byte-identical timestamps.

2. macOS builds were compiled as generic ARMv8-A (#553)

-C target-cpu=native resolves to bare generic on every GitHub macOS runner. They report Apple M1 (Virtual); LLVM cannot identify the virtualised CPU and falls back to the ARMv8-A baseline. Measured on the runners: native yields exactly one feature, neon — identical to -C target-cpu=generic.

• Loud half: ring asserts at compile time that aes and sha2 are statically present on aarch64-apple-darwin, so it refuses to build. That is the macOS Nightly Canary failure, red weekly since at least 2026-06-08 and diagnosed as an upstream ring 0.17.14 regression to wait out. It is neither upstream nor a regression: reproduced locally on the pinned toolchain with -C target-cpu=generic, byte-identical E0080s at darwin.rs:44 and :51. ring is right to assert — the build was lying about the target. ring 0.17.14 is still the newest release; there was never an update to wait for.
• Silent half: release.yml builds the shipped macOS arm64 binary on macos-latest (image macos-26-arm64) with the same flag, and that runner resolves native to neon on the pinned toolchain. Every macOS binary shipped so far was built without AES, SHA2, CRC, dotprod or fp16. Nothing errored; it was just quietly slower.

Fixed by pinning apple-m1 — the oldest CPU the target can run on, carrying the features the platform guarantees. On an M4, native reports 46 features and apple-m1 34; the 12 dropped are SME matrix / ML dot-product extensions and later architecture baselines (bf16, bti, ecv, i8mm, sme*, v8.5a–v8.7a, wfxt), none used by the MFT parse or Polars query paths. aes, sha2, sha3, crc, dotprod all retained, and macOS builds stop varying with whichever machine produced them.

x86_64-apple-darwin still uses native and is untouched — nothing builds or ships on it here, so there is no evidence to act on.

3. Toolchain pin → nightly-2026-07-21

Deferred since 2026-06-29 on the theory that ring blocked it. That theory was wrong, so the bump is unblocked. just toolchain-sync accepted today's nightly on the first candidate: host clippy --all-features and --no-default-features, Windows cargo xwin clippy, and Linux cargo zigbuild all green before the pin moved. Re-validated after: 2395 tests, lint-prod, lint-tests, and rustdoc with --document-private-items --locked.

Also

fix(docs): two uffs-version intra-doc links pointed at a #[cfg(feature = "build")]-gated item, failing the pre-push rustdoc gate on main. Split into its own commit — unrelated cause, independently revertible.

docs(mft): the forensic_flags accessor comment listed bits 0-2 and stopped, reading as "bit 3 onwards is free". It is not — bit 3 is has_default_data, which feeds compute_tree_metrics, so a new flag landing there surfaces as wrong treesize/tree_allocated far from the cause. That truncated comment caused a real error in review. Completing it pushed types.rs past the 800-LOC policy limit, so the numeric-conversion helpers moved to a new index/convert.rs (re-exported under identical public paths) rather than trimming the docs or taking a size exception.

Verification

2395 tests pass, all pre-push gates green (23 checks incl. Windows xwin clippy), rustdoc clean.

Not yet proven in CI: no run has compiled this repo with target-cpu=apple-m1. The macOS canary is schedule/dispatch-only, so a green PR does not confirm it. Dispatching the canary against this branch is the run that actually closes that loop.

Closes #553.