fix: prefer DSH packages in npm repository lookup

[fwerkor]

Summary

• search a full npm search page before applying the existing exact repository URL check
• when multiple npm packages point at the same GitHub repository, prefer one explicitly tagged with the dsh-plugin keyword
• preserve the existing first-match fallback for repositories with only ordinary/unmarked package metadata
• add offline regression coverage for monorepos that publish both a CLI/helper package and a DSH plugin

Problem

The npm reverse lookup currently uses size=10 and returns the first exact-repository match. npm's search endpoint is relevance-ranked rather than a repository index, so an exact match can be far outside the first 10 results. A repository can also legitimately publish multiple packages; in that case the first result may be a CLI/helper package rather than the DSH plugin.

A concrete example is fwerkor/local-shell-mcp: it publishes an npm CLI launcher and is adding a separate DSH package. The launcher is not a DSH plugin, but the current lookup can select it solely because both packages belong to the same repository. This led to install reports fwerkor/local-shell-mcp#260 and #261.

Validation

• npm run typecheck:server
• node --test tests/npm-resolve.test.ts (6/6 passed)
• npm run check (103 tests, 101 passed / 2 skipped; typecheck and full build passed)

[dshplugin]

Thanks for the fix, @fwerkor! Nice catch — the npm search endpoint is relevance-ranked, so relying on size=10 plus a first-exact-match was indeed fragile. Scanning a full search page and then preferring the package explicitly tagged with the dsh-plugin keyword (with a sensible first-match fallback) is exactly the right behavior, and it directly addresses the local-shell-mcp mis-selection.

The three offline tests (monorepo prefers the DSH package, single-package fallback, and ignoring non-target repos) are well chosen and keep the selector covered.

Merged into main (a7fd855) — it will ship in the next release. Thanks again for the contribution!