doctor --fix silently skips every repair when brew or winget is absent

[alpCaner]

Found while reviewing

PR #352, feat/v06-batch at 1cab240df85d5896c5390697c069720ff2bb24d3.

doctor_cmd.run_fix resolves the first word of each manifest-owned install command through on_path. If it cannot resolve that executable, it immediately continues and emits no outcome check:

resolved_exe = on_path(argv[0])
if resolved_exe is None:
    continue

The new test explicitly pins this silence for a missing winget.

Why this is reachable

The real alp-sdk manifest uses:

macOS:  brew install git/cmake/python3/ninja/xz/wget
Windows: winget install ...

A fresh/minimal macOS host without Homebrew or a Windows image without a usable winget reports tools missing, accepts doctor --fix, then produces no fix:* check for any command because the package manager itself is absent.

This contradicts run_fix's own stated invariant that each entry is either run or refused and that every outcome becomes a check. The user sees the original doctor failures with no indication that --fix did nothing.

Impact

The least-equipped hosts—the primary audience for --fix—get the least diagnostic behavior. They cannot distinguish “nothing needed fixing” from “tan could not find the installer needed to attempt any fix.”

Acceptance criteria

• An unresolved installer executable emits a named outcome such as doctor.fix-installer-not-found, including the installer and affected tool.
• Text and JSON modes both explain that no repair ran.
• Multiple tools sharing the same missing installer are reported without misleading duplicate guidance.
• The existing test expecting [] is replaced with a verdict assertion.

Related: #91, PR #352.

[alpCaner]

Fixed on dev in ac79d4c (PR #352). dev IS this repo's default branch so Closes does fire, but this issue was filed after the PR body's closing-keyword list was written and was never added to it; a merged PR body cannot close retroactively.

run_fix no longer does resolved_exe = on_path(argv[0]); if resolved_exe is None: continue. An unresolved installer emits doctor.fix-installer-not-found naming the installer AND the affected tools, deduped so one absent brew covering six tools does not print six identical paragraphs. The test that pinned the [] silence asserts the verdict instead.

Verified in a pristine ubuntu:24.04 on the merged freeze: fix_installer_not_found_check returns a Check, so it is printed by doctor's per-check loop in text mode as well as carried in JSON — checked directly rather than assumed, while investigating #375.

Related follow-up, now also fixed (#375): the suppression path had the opposite problem. When the consent gate blocks --fix entirely (no TTY), the notice was JSON-only, because doctor's text branch never read issues at all outside the exception path. That closed a second silent producer too — project_pin_issue (#263).