fix(doctor): stop reporting a healthy Yarn PnP project as broken

[robmclarty-minga]

Stacked on #4. This branch is based on fix/resolve-slot-tools-locally, because the PnP detection belongs in the src/pm/tools.ts resolver that PR introduces. A fork PR's base has to be a branch in this repo, so I couldn't target #4 directly — hence this PR shows both commits. Merge #4 first and this collapses to the single fix(doctor) commit. Review only 9511268 if #4 is already reviewed.

The problem

A Yarn Plug'n'Play project has no node_modules/ at all — the install artifact is .pnp.cjs, and binaries resolve through Yarn's runtime rather than a node_modules/.bin directory. Both of doctor's install questions were path tests against a tree that layout never produces:

• checkInstall asserted node_modules/ exists → reported install: missing, found "lockfile only"
• probeTool looked for node_modules/.bin/<tool> → reported every tool missing

Both rows are required: true, so doctor exits 1 and declares the environment broken — on a repo where every tool is installed and every check passes. Demonstrated on a real Yarn 4 PnP fixture with markdownlint-cli2 genuinely installed:

package manager: yarn (detected)
✘ install                lockfile only  (node_modules/ populated)
    -> Run `yarn install` from the repo root.
✘ docs   markdownlint-cli2  default  not installed
✘ environment has problems (see above)

...while the gate on the same repo, same moment:

✔ docs        453ms  Markdown linting
✔ all checks passed

The two commands contradict each other, and #4 sharpens that: it makes the run path deliberately PnP-safe (the pre-flight is scoped to the npm/bun launcher caches, and yarn <tool> resolves through the PnP runtime) while leaving doctor's assumption in place. I flagged this while writing #4 but it never made it into that PR body — my omission.

The change

Detect the layout, then ask the question that layout can answer:

• install is satisfied by .pnp.cjs plus the lockfile. Reports .pnp.cjs + lockfile (Yarn PnP).
• A slot's tool is resolved with yarn bin <tool>, which prints the path and exits 0, or exits 1 when the tool isn't a dependency — so the exit code carries the whole answer. Shares the version probe's timeout, since this spawns a package manager and a hung doctor is worse than an unresolved tool.

isPnPInstall lives in src/pm/tools.ts beside the other resolver, so the run path and doctor keep sharing one answer about where a tool lives. It recognises .pnp.cjs, .pnp.js (Yarn 2) and .pnp.data.json, and deliberately does not walk up — PnP is per-project, and a parent's manifest says nothing about how this project is installed.

Two guards worth reviewing specifically:

1. It must not become optimistic. A tool that genuinely doesn't resolve still reports missing — the PnP path asks a looser question, not a softer one. Trading a false red for a false green would be the worse bug, so there's a dedicated test for it.
2. Gated on yarn. PnP is a Yarn feature, so a .pnp.cjs left behind by a migration off Yarn can't reroute an npm or pnpm repo into asking npm bin for its tools. Also tested.

Verification

Against a real Yarn 4 PnP fixture (.pnp.cjs, .pnp.loader.mjs, .yarn/, no node_modules), both directions:

	doctor	run
tool installed	✔ install / ✔ docs / environment ok	✔ docs green
tool removed	✔ install / ✘ docs missing	✘ docs red

Note install correctly stays green in the second row — the project is installed, it's just missing that one tool. The two commands now agree in both directions, which was the whole point.

Plus 7 unit tests: the three PnP manifest names, no-walk-up, the non-PnP layout, PM-resolution success and failure, and the stale-.pnp.cjs guard.

Note on health

The first cut of this pushed probeTool to CRAP 31.6 (cyclomatic 10, cognitive 14) and turned the health slot red. I split it rather than baseline it: probeTool now dispatches on adapter shape and probeExecTool owns the two-layout resolution. health is green.

Same pre-existing failure as #4

pnpm check is green on every slot except test, which fails the same 2 signal-timing tests in src/triage/__tests__/env.test.ts. Those are an artifact of my sandboxed environment: they pass on a normal machine and passed on all four CI jobs for #4 (ubuntu + macos × node 22.18/24). Not related to this change.