Improve doctor diagnostics for agent, OS, PATH, and network troubleshooting

[tuchg]

Summary

Improve lucarned doctor so it gives enough environment detail to debug install, agent, service, and connectivity issues without asking users to run several separate commands (lucarned paths, which -a, brew info, manual version checks, network probes, etc.).

Recent Homebrew troubleshooting showed that doctor reports agent binary paths, but it does not show versions or PATH shadowing details. It also leaves some useful install/runtime context split across paths and external commands.

Current behavior

Example output today:

ok: lucarned: /opt/homebrew/bin/lucarned
ok: lucarned-help: lucarned --help succeeded
ok: config: /Users/era/.lucarned/lucarned.yaml
ok: logs: /Users/era/.lucarned/logs
warn: autostart: launchagent /Users/era/Library/LaunchAgents/com.tuchg.lucarned.plist (Bad request.)
ok: codex: /opt/homebrew/bin/codex
ok: claude: /Users/era/.local/bin/claude
ok: pi: /Users/era/Library/pnpm/pi
ok: gemini: /Users/era/.asdf/installs/nodejs/22.12.0/bin/gemini
ok: copilot: /opt/homebrew/bin/copilot
ok: update: current version 0.3.0 (latest 0.3.0)

This is useful, but support still needs extra commands to answer basic questions:

• Which lucarned is actually being executed?
• Is Homebrew's binary shadowed by another install under ~/.lucarne/bin or ~/.cargo/bin?
• What versions are the local agent CLIs using?
• What OS/arch/service manager is this running under?
• Can the host reach GitHub release APIs or configured channel endpoints?
• Which output from lucarned paths is relevant, and which command should users run first?

Proposed improvements

1. Report local agent versions

For each detected optional agent CLI (codex, claude, pi, gemini, copilot), include:

• resolved path
• version output, if a cheap and bounded version command is known
• clear warning if version probe fails or times out

Example:

ok: codex: /opt/homebrew/bin/codex (codex 0.48.0)
ok: claude: /Users/era/.local/bin/claude (Claude Code 2.0.42)
warn: gemini: /path/to/gemini (version probe timed out after 2s)

Version command behavior should stay provider-owned where possible, not hard-coded as ad hoc common-layer provider logic.

2. Add install and PATH diagnostics

Include paths-style details inside doctor, or add a doctor --verbose mode that prints them:

• current executable path
• install bin dir
• config file, state DB, log dir
• autostart entry path
• all lucarned candidates on PATH
• warning when the first lucarned on PATH differs from the expected install/service binary

This would have made the Homebrew vs ~/.lucarne/bin shadowing issue obvious from one command.

3. Add OS and runtime context

Report platform facts useful for support:

• OS name and version
• kernel version
• architecture
• current user
• shell if available
• service manager/autostart mechanism (launchd, systemd --user, etc.)
• Homebrew prefix/formula version when Homebrew install is detected

4. Add bounded network diagnostics

Add network checks with short timeouts and no secrets:

• GitHub release API/release download reachability for update checks
• DNS/TLS/connectivity status summary
• proxy-related environment variables by name only (HTTP_PROXY set/unset, not value)
• optional channel endpoint reachability based on enabled config, redacting tokens and IDs

Example:

ok: network-github: api.github.com reachable in 230ms
warn: network-github-release: timed out after 3s
ok: proxy: HTTP_PROXY unset, HTTPS_PROXY set

5. Reduce redundant support commands

lucarned doctor should be the main first-response support command. lucarned paths can remain useful for scripting, but human troubleshooting should not require running both commands plus which -a, brew info, and separate agent --version checks.

Acceptance criteria

• lucarned doctor remains concise by default, or supports lucarned doctor --verbose for expanded diagnostics.
• Output includes local agent CLI path + version where available.
• Output includes OS/runtime/install-method basics.
• Output warns about PATH shadowing and multiple lucarned candidates.
• Output includes bounded network checks with redacted sensitive data.
• Existing Linux diagnostics remain available.
• Tests cover parsing/rendering for version probes, PATH shadowing, and network timeout/error rendering.