fix: let the satisfied-PR closer consult the manifest, and reject phantom paths from PR bodies

Two bugs caught live by the newly dogfooded workflows (#1445) — a check run against real PRs surfaced both within minutes.

A fully satisfied PR could never close

checkAndCloseSatisfiedPRs verified each PR package against the current outdated-scan. But the scan lists only what is still outdated — so a fully satisfied PR has, by definition, zero packages in it. Every package fell into the unverifiable bucket, and the (correct) mass-closure guard kept the PR open forever. The only closable shape was the partial one: a package still outdated overall but beyond the PR's older target.

Live evidence: PR #1364 (typescript → 7.0.2; main already declares ^7.0.2) survived today's check run as "no satisfied PRs found".

The scan-absent branch now consults what package.json declares: at-or-beyond → positively satisfied; behind → still needed (the scan missed it); undeclared → unverifiable, exactly as before. Non-npm ecosystems keep the conservative path. The inner scan Buddy also inherits projectPath now instead of silently scanning process.cwd() — same defect family, one line.

Badge markdown parsed as a "removed file"

The same run logged:

PR #1364 references removed files: [![adoption](https://developer.mend.io/api/mc/badges/…

extractFilePathsFromPRBody's table regex accepted any cell containing a / — renovate-era bodies are wall-to-wall badges and links. Only lucky downstream guards kept that from auto-closing a live PR. Captures now pass an isPlausibleRepoPath gate (no whitespace, no markdown syntax, no URLs) before they count as paths.

Tests

Four new cases: manifest-satisfied close (the #1364 shape), manifest-behind keep, badge-table extraction yields nothing, real file cells still extract. Full suite 2384 pass / 0 fail; typecheck and pickier clean.

After this merges, the next check run should close #1364 on its own.

🤖 Generated with Claude Code