fix(github-mcp): vendor bash-mcp-sdk v2.0.0 to enforce union types

[Martin Bens (SpiGAndromeda)]

Bumps the vendored protocol handler from shopwareLabs/bash-mcp-sdk v1.0.0 to v2.0.0 and corrects the two places in the docs that named the old pin.

Why

Every numeric identifier parameter across tools-read.json and tools-write.json declares "type": ["integer", "string"], because clients send an issue or PR number both ways. v1.0.0 of the SDK read a list-valued type as no constraint at all — the validator's type check selected on ($t | type) == "string" and skipped everything else — so those 37 parameters were unvalidated. A boolean or a float reached gh untouched.

v2.0.0 normalizes a declared type to a list and accepts a value that matches any member, on a property and on items.type alike. A list that is empty or holds a non-string member is treated as malformed and left unenforced rather than rejecting everything.

What changes for callers

Call	Before	After
issue_view {"number": 339}	accepted	accepted
issue_view {"number": "339"}	accepted	accepted
issue_view {"number": true}	accepted, passed to gh	isError: number expected integer or string, got boolean
issue_view {"number": 3.5}	accepted, passed to gh	isError: number expected integer or string, got number (non-integer)

The SDK calls this a major release for that reason. In this repository the rejected shapes are calls no client makes deliberately, and the stricter-validation entry it extends is still under [Unreleased], so no version bump accompanies it.

Contents

• .mcp-sdk.lock → v2.0.0, and plugins/github-mcp/shared/mcpserver_core.sh re-vendored by .github/scripts/vendor-mcp-sdk.sh. The file is byte-identical to lib/mcpserver_core.sh at that tag; the validator is the only thing that moved between the two releases.
• plugins/github-mcp/CHANGELOG.md: the [Unreleased] entry named v1.0.0 and stated that the pinned SDK does not enforce array-valued types. Both are now false, so the entry says what v2.0.0 does instead.
• plugin-tests/github-mcp/tool_schemas.bats: the "default satisfies the constraints declared beside it" check only looked at string-valued type, so a default on a union-typed property skipped it entirely. It now normalizes the declaration the same way the validator does. No shipped schema has such a default today — this keeps a future one from slipping past.
• plugins/github-mcp/AGENTS.md: External References pointed at muthuishere/mcp-server-bash-sdk, which the vendoring superseded. It now names the SDK the file actually comes from and the lock that pins it.

No test was added for the union enforcement itself. That is the SDK's own behavior and it is covered by tests/mcp_argument_validation.bats upstream; this repository tests the seam, not its dependency.

[Deemwar Monads and abstractions (deemwario)]

The union-type fix here is a sharp catch — a list-valued type silently unenforced meant 37 parameters were accepting anything. Went and read the v3.0.0 validator afterward out of curiosity about how far the type-checking goes, and it's unusually careful: the comment block around type_ok's integer branch documents its own known gap (a value smaller than the smallest subnormal double, like 1.5e-400, gets misclassified as an integer because floor underflows it to exactly zero and the literal's rendered exponent short-circuits the fractional-digit check).

Verified that one independently rather than take the comment's word for it:

$ jq -n '1.5e-400 == (1.5e-400 | floor)'
true
$ jq -n '(1.5e-400 | tojson) | test("[eE]")'
true

Both hold exactly as documented, so type_ok(["integer"], 1.5e-400) does return true. Worth saying plainly since it's easy to read a documented-gap comment and assume it's theoretical: this one reproduces on the first try. Doesn't look worth a fix given the value range involved — no real integer parameter (an issue number, a PR id, a count) is ever going to arrive as a value smaller than 1e-300 — but it's a nice example of the difference between "our tests pass" and "we know exactly where the boundary is and chose not to chase it," which is a rarer thing to see documented this precisely in a bash JSON validator.