Summary

• The macOS df unit tests (TestDfDataRowsAreNumeric_POSIX, TestDfPercentFormat, TestDfTotalSumIsConsistent) parsed rows with strings.Fields() + fields[len(fields)-N] indexing. That counts tokens from the end, so any row whose source (Mntfromname) or mount point (Mntonname) contains whitespace silently mis-attributes column values.
• The macos-latest GH runner happened to expose this on commit 2904b38 — see the flaky failure at actions/runs/26100876847/job/76751213250 — when a Cryptex volume row tripped the test even though the df output itself looked fine. Re-runs on different macOS runner instances are passing — so the failure is runner-dependent, but the underlying test fragility is real.
• This PR replaces the token-count parsers with regexes anchored on the unambiguous blocks used avail capacity numeric quartet. The anchor doesn't care how many tokens the source or mount point split into, so column identities stay correct regardless of embedded whitespace.
• Same hardening applied to the -PT (TestDfTypeFilterMatchesAtLeastOne, TestDfExcludeTypeRemovesRows) and -h (TestDfHumanReadableHasNoDigits_AtLargeSizes) sibling tests that used the same fragile indexing.
• TestDfTotalSumIsConsistent now skips (rather than fails) if any data row is non-standard, since the per-row sum can't be bounded against the implementation's total when some rows aren't parseable.

Test plan

• go test -race -timeout 60s ./builtins/df/ passes locally on macOS
• Regex traced against: standard rows, map auto_home (space in source), hypothesized Cryptex shapes (space in source and/or mountpath), sources with embedded digits (/dev/disk1s5), - capacity sentinel, total row, -PT rows with the fstype column
• make fmt clean
• CI passes on macos-latest, ubuntu-latest, windows-latest