test(cli): the codex temp-dir cleanup test watches the dir the adapter built, not the whole of $TMPDIR (TASK-073)

[lilyshen0722]

One test in the cli suite is red on roughly one full-suite run in five — inside the only
required check on main. It is not a bug in the adapter. It is an assertion that measures
the whole machine.

cli/__tests__/adapters.codex.test.mjs › cleans up the per-spawn temp dir even when spawn rejects counted commonly-codex-* entries in os.tmpdir() before and after one failing
spawn, and required the two counts to be equal. That number is process-global:

• cli/src/lib/adapters/codex.js:442 is mkdtemp(join(tmpdir(), 'commonly-codex-')) — a
  spawn in any parallel jest worker adds one between the two reads;
• this file's own commonly-codex-operator-home-* / -public-home-* dirs match the same
  prefix;
• and the read after the spawn races the adapter's own asynchronous rm in finally.

Measured

where	runs	red
full cli suite, main @ e77b1b47	15	3
full cli suite, the #1764 branch	15	3
this file alone	10	0
full suite, after this change	15	0

The rate is the same on main and on a branch that touches neither this test nor the
spawn path, so it is pre-existing. Alone, the file never flakes — the trigger is another
suite's spawn, not this test's own logic. I never captured which direction the count moved
(one extra dir vs one fewer), because the fix does not need to know.

This is a required-check defect, not local noise. Run CLI tests is a step inside the
test job of .github/workflows/tests.yml (step at :147, job declared at :41, job body
ends :165) whose display name is Test & Coverage — the single required check on main,
with strict: true. A 1-in-5 flake there is a 1-in-5 spurious red on the merge gate.

The change

The test now asserts on the path the adapter itself built, taken from the argv it handed
the _spawnImpl seam (-o <dir>/last-message.txt), instead of counting names in $TMPDIR:

• the control runs inside the spawn seam: the dir must exist at that moment, and it is the
  path parsed out of the adapter's own argv — so the test cannot pass by watching a path it
  invented, and cannot pass on an adapter that creates nothing;
• after the rejection the same path must be gone (lstat(...) → null), which is the
  finally the test exists to guard.

No polling, no retry, no --runInBand, no env mutation: the dir is private to the spawn, so
nothing concurrent can move the answer. Test file only — no cli/src change, so no version
bump is required and this takes no slot on the release ladder.

Both assertions are load-bearing — mutations, not reruns

A fix for a flake has to be proven by making the defect it guards reproducible, so each
mutation was run and the result asserted, twice:

mutation in cli/src/lib/adapters/codex.js	file alone	full suite
the finally rm removed (the defect this test guards)	red 3/3 runs	1 failed / 589 passed — this test, deterministically
mkdtemp prefix changed to something else	red 2/2 runs	— (the attribution assertion)

The first row is the point: before this change, dropping the adapter's cleanup was caught
only when the global count happened to be stable. Now it is caught every time.

Limits

• I did not reproduce the flake after the fix in 15 runs, which is consistent with a
  ~20% pre-fix rate but is not proof of absence — the proof is the second mutation row:
  the assertion is now a private fact, so concurrency cannot move it.
• The commonly-codex- prefix match is deliberately retained (expect(spawnDir).toMatch(...))
  so a future rename of the adapter's temp root is a visible test failure rather than a
  silent one.
• Only that one test changed; the other 25 in the file are untouched.

TASK-073. Filed from Vera's carry note on #1764 (69971), which recorded the unexplained red
without holding on it.