fix(test): stop asserting client_path always passes in mcp-cli-doctor.test.ts

Genuinely pre-existing, unrelated to any of the build/caching work on
this branch (confirmed: zero commits since this branch's base touch
this file). Only surfaced now because earlier CI failures on this
branch were catastrophic enough (every mcp-cli-*/miner-* test failing
on a missing binary) to mask this one underneath.

doctor's "local_repo_readiness" group includes a "client_path" check
that scans process.env.PATH for a "loopover-mcp" executable via a
plain findExecutable() -- in practice this resolves through npm's own
workspace bin-link at node_modules/.bin/loopover-mcp. npm only creates
that symlink if the bin target (bin/loopover-mcp.js) already exists at
`npm ci` time. Since build(mcp,miner): stop committing compiled .js/
.d.ts entirely stopped committing that file, every CI job's npm ci now
runs before any build step ever does, so the symlink is never created
there -- regardless of a later build succeeding. The check itself
already treats this gracefully (status "warn" with remediation
guidance, never "fail"), but the test hardcoded status: "pass" for the
whole group, which only happened to hold locally because of a stray
global @loopover/mcp install left on this machine's own PATH from
earlier, unrelated testing -- not something any CI runner, or a fresh
contributor checkout, would ever have.

Verified by literally reproducing the CI condition: moved my own
machine's global loopover-mcp symlink aside, confirmed `which
loopover-mcp` finds nothing (matching a clean CI PATH), ran this exact
test file against that state -- all 19 tests pass, including this one.
Restored the symlink afterward.

Author: JSONbored

test/unit/mcp-cli-doctor.test.ts

@@ -55,12 +55,22 @@ describe("loopover-mcp CLI — doctor", () => {
       expect.arrayContaining([
         expect.objectContaining({ id: "auth", title: "Auth", status: "pass" }),
         expect.objectContaining({ id: "api_compatibility", title: "API compatibility", status: "pass" }),
-        expect.objectContaining({ id: "local_repo_readiness", title: "Local repo readiness", status: "pass" }),
+        // Not asserting status here: this group's own "client_path" sub-check (findExecutable("loopover-mcp"))
+        // does a plain PATH scan for a "loopover-mcp" executable, which resolves via node_modules/.bin's npm-
+        // workspace bin-link -- but npm only creates that symlink if bin/loopover-mcp.js already exists at
+        // `npm ci` time. Since compiled output is no longer committed (build(mcp,miner): stop committing
+        // compiled .js/.d.ts entirely), every CI job's npm ci runs before any build step, so the symlink is
+        // never created there, regardless of a later build -- this group's status is genuinely "warn" in that
+        // environment and "pass" only where something else (a real global install, e.g.) already put
+        // loopover-mcp on PATH. Checked explicitly below instead, tolerating either.
+        expect.objectContaining({ id: "local_repo_readiness", title: "Local repo readiness" }),
         expect.objectContaining({ id: "scorer_availability", title: "Scorer availability", status: "warn" }),
         expect.objectContaining({ id: "output_safety", title: "Output safety", status: "pass" }),
         expect.objectContaining({ id: "next_command", title: "Next command", status: "warn" }),
       ]),
     );
+    const localRepoReadiness = payload.checklist.find((group) => group.id === "local_repo_readiness");
+    expect(["pass", "warn"]).toContain(localRepoReadiness?.status);
     expect(payload.nextCommand).toMatchObject({
       command: "loopover-mcp doctor --json",
       reason: expect.stringContaining("local scorer"),