Flaky CI: tests/cli/work.test.ts > 'clears handoff with --clear' (work handoff --clear exits 1 under CI load)

[vilosource]

Symptom

On CI (GitHub Actions, 2-core, under vitest cross-file parallelism),
tests/cli/work.test.ts > kb work CLI > handoff > clears handoff with --clear intermittently fails:

AssertionError: expected 1 to be +0   // expect(exitCode).toBe(0)

i.e. the kb work handoff --clear CLI subprocess exits 1 instead of 0.

Evidence it is a pre-existing, non-deterministic flake

• Observed once on PR feat(daemon): v2 privileged-write-channel daemon scaffold (phase 2) #22's CI (run 25951906810); a sibling run on the
  same tree (25951896448) passed; a --failed re-run also passed.
• Unrelated to the PR's changes (feat(daemon): v2 privileged-write-channel daemon scaffold (phase 2) #22 was src/daemon/* only; this is
  kb work CLI subprocess plumbing).
• Same area is already known-fragile — cf. the recent
  ci: pre-build CLI bundle before vitest to dodge worker RPC timeout
  commit. Likely an isolation / CLI-bundle-staleness / spawn-timing race
  in work.test.ts (heavy 55-test, ~30s file) under loaded CI.

Why it matters

It threatens every PR in the v2 privileged-write-channel chain (and the
repo generally) with red CI that requires a manual re-run.

Suggested fix direction

Harden tests/cli/work.test.ts against CI load: ensure the CLI
bundle/build is fresh before the subprocess runs, increase per-runKb
robustness (retry/await on the spawn), or isolate the heavy CLI-subprocess
E2E files from cross-file parallel contention (a vitest projects split
for process-spawning E2E — same class as artifact-isolation.test.ts).

Tracking-only; not blocking the v2 chain unless it reproduces
deterministically (per maintainer decision 2026-05-16).