fix(mcp): only derive a package from the manager's executor subcommand

[alexviktorov]

What

For npm/pnpm/yarn/bun, derive a package identity only from the manager's
package executor: npm exec/npm x, pnpm dlx, yarn dlx, bun x (or the separate
npx/bunx). Any other first token runs a local script, file, or binary, so it yields
no spec and the record falls back to the server id at confidence=low — the same rule the
parser already applies to uv run <script>.

Bug

MCP servers launched through a script runner had the script or file name recorded as the
package. The claude-plugins-official messaging plugins launch their bundled server with

{ "command": "bun", "args": ["run", "--cwd", "${CLAUDE_PLUGIN_ROOT}", "--shell=bun", "--silent", "start"] }

and a baseline scan of a machine with them installed records package_name="start" for
discord, imessage, telegram and fakechat. start is a real npm package, so a catalog
entry for it would spuriously match. The same leak shows up as:

launcher	main records	expected
bun run … start	start	server id
bun server.ts / bun run src/index.ts	server.ts / src/index.ts	server id
bare yarn dev	dev	server id
yarn exec node dist/index.js, pnpm exec node …	node (a real npm package)	server id

exec fetches a published package only under npm. pnpm exec runs a locally installed bin,
and yarn/bun exec run a shell command, so it is not an executor there — hence a
per-manager packageExecutors table rather than one shared subcommand set.

Evidence

The new unit rows and corpus entries fail on main with the leaked values (13 rows, 5 entries):

inferPackageFromArgs("bun",[run --cwd /x --shell=bun --silent start]) = ("start",""), want ("","")
inferPackageFromArgs("bun",[run src/index.ts]) = ("src/index.ts",""), want ("","")
inferPackageFromArgs("yarn",[exec node dist/index.js]) = ("node",""), want ("","")
discord: got package_name="start" package_manager="mcp", want "discord"/"mcp"

Package executors are unchanged: npx/bunx, --package, the -- terminator and
credential-bearing value flags keep their identity (existing tests, plus a new
--registry … exec @scope/pkg row).

Trade-off, pinned in a test: a bare yarn <installed-bin> also falls back to the server id.
The scanner cannot tell a script from a bin without reading package.json, and a
low-confidence server id beats a wrong package guess.

Files

internal/ecosystem/mcp/mcp.go (per-manager packageExecutors, doc comment),
internal/ecosystem/mcp/mcp_test.go, docs/inventory-sources.md. Rebased on current
main; go build, go vet, gofmt -l, go test -race ./... and bumblebee selftest pass.

[alexviktorov]

@adel-pplx Let me know if you need any context on this. Basically after scanning my Mac I saw several records listing "start" as the package, where it's evidently a command. Specifically it was for some Claude official plugins. This PR fixes the discrepancy and instead you get the actual names, similar to other places in code. Tested on my local config and generated synthetic unit tests from real world examples. Thank you!