test(cli): stop the tree tests depending on ambient colour detection

[justin13888]

Closes #100.

Three tree tests fail on an unmodified checkout whenever FORCE_COLOR is set, while CI — which does not set it — stays green:

$ FORCE_COLOR=3 cargo test --workspace
failures:
    output::tree::tests::ascii_points_a_member_at_its_own_tree
    tree_distinguishes_workspace_and_external
    a_member_used_by_another_member_points_at_its_own_tree

Cause

label styles through text.if_supports_color(Stream::Stdout, …). owo-colors delegates that to supports-color, which honours FORCE_COLOR ahead of the TTY check. Both test sets assumed the check would answer "no" — the unit tests because a harness captures stdout, fixture_tree.rs explicitly ("Piped stdout is not a TTY, so labels are plain (uncolored) and assertable as text"), with the spawned child inheriting the parent's environment. Both are defaults, not guarantees, and FORCE_COLOR is exported by terminal multiplexers, task runners and CI images.

The consequence is that a contributor whose shell sets it sees mise run test fail on a clean master, cannot tell that failure from a real regression, and is blocked by the pre-push hook.

The change

dependable itself is untouched: honouring FORCE_COLOR through a pipe is what the variable is for, so the product is right and the tests were wrong to assume otherwise. Every failing assertion is about the shape of the tree and none is about its colour, so both sets are made to say that rather than relying on what the process inherited.

• crates/dependable/src/output/tree.rs — a plain test helper runs ascii and strips CSI sequences; the four ascii call sites in the unit tests go through it. Stripping rather than forcing colour off keeps the tests free of global process state, which matters because they run in parallel with each other.
• crates/dependable/tests/fixture_tree.rs — run clears FORCE_COLOR and CLICOLOR_FORCE and sets NO_COLOR=1 on the child. The module doc no longer claims the pipe makes labels plain; it says the environment is pinned.

fixture_tree.rs is the only test file that asserts on styled label text — the other eight that spawn the binary assert on JSON, SARIF, exit codes, or unstyled lines — so no shared helper is introduced for one caller.

Judgement calls

• Strip in the unit tests, pin the environment in the end-to-end ones. They are different problems: the unit tests call ascii in-process, where the only lever is the global owo_colors::set_override, and mutating global state from tests that run in parallel is worse than stripping. The end-to-end tests spawn a child, where per-child environment is precise and local. Reversed by: deciding one mechanism everywhere is worth the parallelism risk.
• dependable gains no --color flag. One would make these tests trivial, but it is a user-facing feature nobody asked for and the tests do not need it. Reversed by: someone wanting to force or suppress colour from the command line, which is worth its own issue.
• The plain helper handles CSI sequences only. That is all owo-colors emits here. Reversed by: a styling path that emits OSC sequences (a hyperlink, say), which would need the helper extended.

Validation

FORCE_COLOR=3 cargo test --workspace                                → 39 test binaries, 0 failures
cargo test --workspace (FORCE_COLOR unset)                          → 39 test binaries, 0 failures
cargo clippy --workspace --all-targets -- -D warnings               → clean
cargo fmt --all --check                                             → clean

Before this change the first of those four fails with the three tests above.

---

Review repairs

An independent review confirmed the diagnosis empirically — under FORCE_COLOR=3, master fails with exactly the three named tests and this branch passes — and traced the plain helper's CSI state machine against the actual supports-color 2.1.0 and 3.0.2 sources: CSI parameter bytes are 0x30..=0x3F and intermediates 0x20..=0x2F, all below the 0x40..=0x7E final-byte range the helper terminates on, so no parameter byte can be mistaken for a terminator and no package name or box-drawing connector can be consumed. It also confirmed NO_COLOR=1 plus the two env_removes is deterministic: removing FORCE_COLOR/CLICOLOR_FORCE empties the override step, and NO_COLOR short-circuits before CLICOLOR, TERM, COLORTERM, is_ci and IGNORE_IS_TERMINAL are consulted.

Two things came back, and both are fixed here.

• A stale comment survived inside ascii_marks_workspace_and_dedupe — // Color is disabled in the test harness (not a TTY), so labels are plain. — asserting exactly the belief this branch exists to remove, ten lines below the helper doc that calls it "a default, not a guarantee". Left in place it invites a contributor to conclude the stripping is redundant and revert plain(…) to ascii(…), reintroducing the bug for that test. Removed.

• Nothing kept the property. The change fixed today's three failures but added no gate, and the exposure is wider than the fix: output/table.rs styles the manifest path and every status cell through the same if_supports_color, and no test file that spawns the binary pins its colour environment — they pass only because their assertions happen not to straddle a style boundary. A mise run test:color task now runs the suite with FORCE_COLOR=3, and CI runs it after the ordinary test step on the Linux leg. Because FORCE_COLOR outranks the TTY check, that is a genuinely second configuration rather than a repeat of the first. The suite is hermetic and runs in seconds.

Validation

mise run test:color   (FORCE_COLOR=3)   → 39 test binaries, 0 failures
cargo test --workspace (FORCE_COLOR unset) → 39 test binaries, 0 failures
cargo clippy --workspace --all-targets -- -D warnings → clean
cargo fmt --all --check → clean

Follow-up: the guard now runs locally too

A second review found the colour-forced suite ran only in CI, so mise run ci and the pre-push hook would both pass a colour-dependent assertion and the failure would arrive from the remote a round-trip later. [tasks.ci] and the pre-push gate now include test:color, and CLAUDE.md's Quality block lists it beside the plain run. Measured cost: the second pass compiles nothing (0 Compiling lines, ~1.6s), because the suite is hermetic and already built by then.

The same review corrected a claim in this branch's first commit message. It cites output/table.rs styling the manifest path and every status cell as the motivation for the guard — but no test asserts on table.rs stdout, and list.rs styles nothing, so the coloured leg's live coverage today is the tree unit tests alone. Its value for table.rs is prospective: it catches the next assertion written across a style boundary, rather than protecting one that exists. Worth stating plainly, because the original wording reads as though table.rs is covered now.

---

Decisions taken

1. How to stop the colour run colliding with the plain run
   Taken: serialize them — the colour task depends on the plain one, in both the mise gate and the git hook.
   Rejected: giving the colour run its own CARGO_TARGET_DIR — it works, and it is what cargo llvm-cov does for itself, but it forces a full second build and roughly ten more gigabytes of target output for a run whose only difference is one environment variable. FORCE_COLOR is in no fingerprint, so a serialized second run rebuilds nothing and costs only its own test execution.
   Rejected: making the scratch fixtures collision-safe instead — that is the deeper fix and closes a wider class, including a std::env::temp_dir() path that can already race the coverage step today, but it touches six test files and is not what put this pull request in the work order. Filed separately.
   Reverses: drop the depends from the colour task and add CARGO_TARGET_DIR to its env instead.

2. Which gates the colour leg belongs to
   Taken: hk pre-push, hk check, mise run ci, and the Linux CI job. check is added here because the file documents it as the manual/CI entry point, and a contributor who passes hk check and is then blocked at push has been told two different things by two gates that claim to be the same.
   Rejected: adding it to the Windows and macOS CI legs — the mechanism is environment-variable driven rather than platform-driven, so one platform establishes it and two more triple the CI bill for no additional signal.
   Rejected: pre-push only, matching the coverage precedent — coverage is explicitly informational with no threshold; this is a pass/fail correctness gate, so the precedent does not transfer.
   Reverses: remove the step from the check hook.

3. Whether the hook invokes cargo directly or shells out to mise
   Taken: invoke cargo directly with the hook step's own env block.
   Rejected: mise run test:color — hk.pkl's own header states the convention that the file defines explicit stable workspace commands rather than delegating, and shelling out additionally makes the hook depend on mise being resolvable in the hook environment, which nothing guarantees.
   Reverses: restore check = "mise run test:color" and drop the step's env block.

4. Whether fixture_tree.rs should keep opting out of the colour configuration
   Taken: keep the pin. That file asserts tree SHAPE, so pinning its child's colour environment makes it deterministic under either leg, and the eight other binary-spawning test files still inherit the forced-colour configuration and provide the coverage the gate exists for.
   Rejected: letting it inherit FORCE_COLOR so the gate covers the file that motivated the issue — the assertions there are about connectors and labels, and re-admitting ambient colour into them re-opens exactly the failure mode this change closes.
   Reverses: delete the three env/env_remove calls in that file's run() helper.

Evidence that the serialization took effect

mise tasks deps ci, before and after:

BEFORE (d58c3bb)          AFTER
ci                        ci
├── test:color            ├── test:color
├── test                  │   └── test
├── lint                  ├── test
└── fmt:check             ├── lint
                          └── fmt:check

hk run check --all --format jsonl, step events in order — fmt, test and clippy all start within 4ms of each other, which is hk scheduling hook steps in parallel; test-color starts 1.4s later, only after test completed:

seq 2  step_started    fmt         16:17:20.162781092
seq 3  step_started    test        16:17:20.166192340
seq 4  step_started    clippy      16:17:20.166256749
seq 5  step_completed  fmt         passed
seq 6  step_completed  clippy      passed
seq 7  step_completed  test        passed
seq 8  step_started    test-color  16:17:21.572976028
seq 9  step_completed  test-color  passed

The no-rebuild claim, from mise run test:color's own output — the second leg's build is a no-op:

[test:color] $ cargo test --workspace
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.18s

Unresolved review notes

• Low — concurrent-unsafe scratch fixtures across the CLI test suite — thirty fixed scratch names under CARGO_TARGET_TMPDIR (eighteen through workdir, twelve through cli_policy.rs's config) wipe themselves on entry, and one fixed path under std::env::temp_dir() sits outside any target directory and can already race the coverage step. Not repaired here: it spans six test files and is wider than the scope that put this pull request in the work order. Filed as test(cli): scratch fixtures use fixed names and wipe on entry, so no two test processes can run at once #119.