feat(doctor): probeRoots for six fixed-location providers (#899 Tier 2, batch 1)

[therickfactr]

Tier 2 of #899, batch 1: probeRoots() for cline, roo-code, kilo-code, grok, pi/omp and kimi.

Standalone rather than stacked on #903 — no provider overlaps its twelve, and the shared-parser extraction below stands on its own. The Tier 2 tests are in their own file for the same reason; happy to fold them into the Tier 1 suite once #903 lands.

Why these six first

cline is the provider whose silence motivated #874, and it still had no probeRoots() — the CLI half got one, the extension half never did. Its four roots (three VS Code variant globalStorage paths plus ~/.cline/data) make the Tier 2 case concretely: four places to look, and no way to see which one CodeBurn found.

Real doctor output on a machine with the Cline CLI installed and the extension not:

│  Cline     │ 0 │ NOTHING FOUND (/Users/…/.cline/data exists but holds no sessions; no history yet)
│  KiloCode  │ 0 │ NOTHING FOUND (/Users/…/globalStorage/kilocode.kilo-code does not exist; tool likely not installed)

Both rows were an unexplained 0 before. Now one says the root is there and empty — the case where the user has the tool and something is wrong — and the other says the tool is not installed.

One shared resolver instead of a mirror

probeRoots() is only worth having if it reports what discovery truly reads, so the resolution is shared rather than duplicated. vscode-cline-parser.ts gains clineTaskRoots(extensionId, overrideDir), discoverClineTasks is rewritten to call it, and the three Cline-family providers use the same function for their probes.

That is the whole change to the shared parser: a pure extraction, no parsing touched. Roo Code, KiloCode and IBM Bob are unaffected — their suites plus the parser's own are green (44/44 across the six affected files).

This is worth spelling out because the first draft of this branch mirrored the logic in a local helper, and the mirror had already drifted before review: it detected "no override" with === undefined while discoverClineTasks uses truthiness. An empty-string override therefore made doctor report [""] while discovery scanned the three default roots — a probe pointing where discovery never looked, stated authoritatively, which is precisely the failure this method exists to prevent. One resolver makes that class unrepresentable; there is a regression test pinning it regardless.

Per-provider notes

• kilo-code reports both halves of its split discovery: the legacy task tree and the SQLite store, labelled separately.
• pi and omp are two providers in one module; each reports its own sessions dir, with a test that they cannot collide.
• kimi reports <shareDir>/sessions, not shareDir. Discovery walks the former; reporting the latter would point doctor at a directory that exists even when no sessions do — exactly the false reassurance this campaign removes.
• Candidate roots are reported before any existence filter, following your lingtai-tui call in feat(doctor): probeRoots for 12 more providers (#899 Tier 1) #903: dropping non-existent dirs is right for discovery and wrong for doctor, whose job is to show where it looked.

Testing

• Tested locally against real data (not just unit tests)
• npm test passes
• npm run build succeeds

Assertions pin exact root sets rather than substrings, so a wrong-but-similar path cannot pass. Each guard is mutation-checked — reverting the resolver to === undefined, making cline's probe ignore its override, and making kimi report shareDir each fail the suite (3 failed / 5 passed with the mutations, 8/8 without).

npm test: 11 failed / 2699 passed. Every failure is pre-existing on main — 1 assertion failure and 10 timeouts, all in cache-refresh-lock and app/electron/cli. I ran cache-refresh-lock on clean main and on this branch and got identical results, so it is not introduced here; it looks like the lock family from #914 has not fully settled.

Open question from #899

Still unanswered, and it shapes batches 2 and 3: for providers whose discovery globs (e.g. ~/.gemini/tmp/<project>/chats), do you want the glob parent reported, or the resolved matches? Parent is cheap and stable; resolved matches are more useful but turn doctor into a directory walk. I have gone parent-only here, consistent with the cheap-existence-check shape, and will keep doing so unless you say otherwise.