doctor: exit CONFIG_ERROR when a required check fails

[ankitranjan7]

Summary

• webcmd doctor always exited 0 regardless of what it found — `src/doctor.ts` contains no exit-code handling and `src/cli.ts` doctor action only rendered the report. A diagnostic that reports success on an unhealthy machine can't gate an agent's next step.
• Adds `doctorRequiredChecksFailed(report: DoctorReport): boolean` next to `DoctorReport`. Required = `daemonRunning`, `runtimeConnected`, `connectivity.ok`. Soft warnings collected in `issues` (e.g. an unreadable adapter-override directory) do NOT fail the exit code. Absent `connectivity` = probe never ran = not a failure.
• Wires it into the `doctor` command: report still renders to stdout in full, and on failure process.exitCode = EXIT_CODES.CONFIG_ERROR (78).

Test plan

• Six new predicate unit tests in `src/doctor.test.ts`: healthy → false, soft-issue-only → false, three failure modes → true, absent connectivity → false.
• One command-level test asserting `process.exitCode === EXIT_CODES.CONFIG_ERROR` when a required check fails.
• Full doctor + programmatic-differential suite green (90/90), typecheck clean.

⚠️ Breaking change

webcmd doctor now exits 78 (CONFIG_ERROR) on an unhealthy machine. Scripts that call webcmd doctor and check $? will start seeing 78 where they saw 0. The structured JSON/YAML report on stdout is unchanged; only the exit code differs.

Notes

• Part 3 of 3 slices from a hosted-parity design. The forthcoming hosted doctor (a later PR that lands with the Cloud diagnostics endpoint) will use the same exit contract — this PR aligns local first so the two modes can't disagree.

🤖 Generated with Claude Code

[github-actions]

🟠 Maintainer review suggested — low confidence

The automated review could not reach a fully supported conclusion.

Limitations

• The automated review returned an invalid structured result.

This review is advisory and does not block merging.