Return directory entries in name order (fixes #179)

[typeless]

readdir order is where filesystem nondeterminism enters putup. Every consumer was responsible for canonicalizing it — a conventional invariant — and two of the five consumers did not: glob expansion (#171) and discover_variants (#175). The first put readdir order into %f and therefore into command identity.

read_directory now sorts entries by name on both platforms, and walk_directory inherits it because both implementations enumerate through read_directory. Enumeration order becomes a function of directory content at the one site that produces it, instead of at each consumer that remembers to ask. The guarantee is stated at the declaration, since that is what callers read.

The same boundary in tup is already ordered: listings come from node_dir_index (dir, name).

Demonstrated

This branch carries neither downstream fix, so the variant hint shows the boundary alone doing the work. Six build dirs enumerating (ls -U) as yankee mike charlie bravo alpha zeta:

Error: no build directory specified; found: build-alpha, build-bravo, build-charlie, build-mike, build-yankee, build-zeta

What this does not replace

Boundary sorting gives determinism, not canonical path order, for recursive walks: DFS pre-order over per-directory sorted entries is not lexicographic — sub.txt sorts before sub/a.txt as a string, while the walk emits sub/a.txt first because it descends sub on the way past. glob_expand's own sort (#174) is still what makes %f path-ordered, and #176's sort still states the intent locally rather than depending on a remote invariant.

Tests

Two scenarios: read_directory returns name order, and walk_directory enumerates every level in name order depth-first. The RED artifact depends on the filesystem — the tests create entries in reverse-lexicographic order, so they fail on a creation-ordered filesystem and a hash-ordered one alike. Observed here as { alpha, zeta, charlie, mike, yankee, bravo }.

The win32 half is compile-checked by CI only; it is the same one-line sort in the same position.

make test green (142313 assertions, 618 cases, 32 e2e shards); make tidy and make iwyu clean; bootstrap scripts unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TLob4Ef3qyMd3Dnp9q3XmA

[github-actions]

PR metrics

Performance (gcc example, Linux)

Workload	Instructions	CPU time	Page faults	D1 miss	LL miss	Wall	Peak RSS
parse	1073 M	0.49 s	14.1 k	0.8%	0.1%	0.502 s	30.7 MB (-0.2MB)
dry-run	1786 M	0.6 s	16.6 k	0.9%	0.1%	0.612 s	40 MB (+0.2MB)

Deterministic signals: instructions (cachegrind-simulated instruction reads — exact across runs, no PMU needed), page faults, peak RSS, and the cachegrind D1/LL miss rates. CPU time is user+sys from time(1).

Internal statistics (gcc example, up-to-date dry run)

Metric	Value
Tupfiles parsed	24
Commands	3545
Commands scheduled	0
Files checked	5818
Files changed	0
Files in index	6087
Graph edges	367913
Index size (bytes)	7264970
Implicit deps	330624
Hash computations	0
Hashes skipped (stat cache)	5818
Stat calls	5869
Parse time (ms)	493
Total time (ms)	598.7
Runner CPU	AMD EPYC 7763 64-Core Processor

Counters from putup -n --stat on the fully-built gcc example (up-to-date dry run): deterministic work measures — a jump in commands scheduled, hash computations, or stat calls is a real behavior change, not noise. Timings are the minimum over repeated runs, compared only against a baseline from the same CPU model; the counters are the regression signal.
Timing deltas suppressed: baseline ran on different hardware (AMD EPYC 9V74 80-Core Processor).

Binary size (Linux)

Binary	.text	.data	.bss	File
putup	497 KB (+0.6%)	1.6 KB (-5.9%)	98.7 KB	587.5 KB (+0.8%)

Test coverage (lines)

Overall	Median file	Min file	Max file
86.6%	94.9%	0.0% src/platform/path-posix.cpp	100.0% include/pup/core/arena.hpp

103 files · 14995/17322 lines covered

Deltas vs main@1738aa715.

Updated for 389f021