build: add a single-binary test target

[rustytrees]

Additive build target. zig build test is untouched.

CONTRIBUTING asks for an issue first on anything non-trivial — this is a judgement call about build ergonomics rather than a bug, so I've put the proposal in the PR where the diff is visible. Happy to close it and move the discussion to an issue if you'd rather not review code for something you haven't agreed to in principle.

What and why

zig build test compiles one executable per file under tests/ — 162 of them — and runs 162 fresh processes. Two costs:

• Link time, paid 162 times.
• On a host with a per-binary firewall or endpoint agent, a prompt storm on every run, because each rebuild is an executable the agent has never seen. That is what prompted this; it made the suite genuinely unpleasant to run locally.

zig build test-one links and runs exactly one binary over the same files: 2591 passed, 3 skipped, 0 failed in ~2m20s.

zig build test stays authoritative and unchanged. One process per file is what actually isolates process-global state, and CI should keep using it — test-one is a local convenience and a second signal, not a replacement. tests/all.zig says so in its header.

It found something

Sharing a process surfaced one latent order dependency, fixed here rather than worked around: custom_theme_test's "valid themes file" case asserts on captured CLI output, but emitPrefixLine early-returns while the module-global quiet flag is set. In its own binary the flag happens to be clear; run after a file that leaves setQuiet(true) behind, the capture is empty and the assertion compares against nothing. boot() already pins the colour state for precisely this reason — quiet was the one input it missed.

Worth saying plainly: the per-file layout hides this class of bug, and just test-concurrent covers shared fixture paths, not shared in-process globals. So this target also guards an axis nothing currently checks. I would expect it to find more of these if it runs regularly.

The honest downside

162 files in one process means shared globals, and I only know of the one above. If a future test leaks a global, test-one will fail while zig build test stays green — confusing unless you know why. Two ways to read that: as a maintenance cost, or as the target doing its job. I lean the second, but it is your call, and it is the reason I did not touch the default.

tests/all.zig duplicates the file list from build.zig's test_modules, so a new test file needs adding in two places. I considered generating it at build time, but a generated root in the cache cannot resolve @import("foo_test.zig") relative to tests/. If drift worries you, a no_*_test-style guard comparing the two lists would fit the existing patterns in tests/ — say the word and I'll add it.

Verification

• zig build test-one — 2591 pass, 3 skip, 0 fail, one binary
• zig build test — still green, unchanged

Hope it helps decide the knowledge base.