[Tests] Isolate configureCLIEnvironment environment and color state

[github-actions]

WHY are these changes introduced?

The seven-day review of Main tests runs (2026-09-30T00:28Z → 2026-10-07T00:28Z UTC, all pages, every failed job and attempt) found three failures, all on windows-latest:

• Node 22.12.0, run 36760544046 — version.test.ts > writes the installed version as JSON without stderr output timed out at 20000ms
• Node 22.12.0, run 36793188089 — same test, same timeout
• Node 24.1.0, run 36934506041 — node-package-manager.test.ts > checkForCachedNewVersion > returnes a version string when the cached value is greater than the current version asserted undefined instead of '2.2.3'

All three were already fixed by #8669, which is on main (the three failing commits predate it), and the 19 tests-main runs since have all passed. With no actionable flake left, this picks up a quality issue instead.

packages/theme/src/cli/utilities/cli-config.test.ts leaked state two ways. It reassigned the whole process.env object in beforeEach and only restored the original in afterAll, so any module that captured a reference to process.env saw a different object for the duration of the file. It also set chalk's module-level colors.level in beforeEach and never restored it, leaving the singleton at whatever the last test set — 0 after the noColor: true case.

Two of the noColor tests were also misnamed and under-asserting: both claimed to check the no-color environment variable, deleted it, and then asserted only on colors.level and FORCE_COLOR. Nothing covered the two flags together, or the no-op case.

WHAT is this pull request doing?

Replaces the process.env object swap with per-test vi.stubEnv plus a single afterEach(vi.unstubAllEnvs), so each test declares the variables it depends on and nothing outlives it. Wraps the tests that mutate colors.level in a small helper that sets the level to 1 and restores the previous value in a finally, which removes the afterAll and the last shared mutable state in the file.

Renames the two noColor tests to match what they assert, and adds three cases for behavior that was previously uncovered: an existing verbose variable surviving verbose: false, verbose and noColor applied together, and empty options changing nothing.

Coverage is preserved and tightened — no production code changed. Four mutations of cli-config.ts (always set verbose, always disable colors, drop the FORCE_COLOR write, drop the colors.level write) each fail two tests; before this change the first and third were caught but the misnamed tests left the no-op paths unasserted.

Validated on Linux (ubuntu, Node 22.20.1) with theme:lint, theme:type-check, and the file under five shuffled seeds, the full utilities directory in both threads and forks pools, and a single-worker shuffled run. Three unrelated tests (theme-environment.test.ts snippet-scripts aggregation, html.test.ts lastRequestedPath, and dev.test.ts Ctrl-C analytics) fail under shuffled order, but they fail identically on a clean checkout with the same seeds, so they are pre-existing and out of scope here. The originally failing platform was Windows; these checks were not run there.

How to manually test your changes?

CI

Post-release steps

None.

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add