UriTemplate.match() does not percent-decode extracted values

Describe the bug

expand() percent-encodes variable values, but match() returns them still encoded, so the two are not inverses:

const t = new UriTemplate("file:///{path}");
t.expand({ path: "My File.txt" }); // "file:///My%20File.txt"
t.match("file:///My%20File.txt");  // { path: "My%20File.txt" }  <- expected "My File.txt"

Round-tripping 10 templates against 20 values, 147 of 200 fail — every value containing a space, /, ?, #, &, =, %, or a non-ASCII character. A few from that sweep:

There is no decodeURIComponent call anywhere in packages/core-internal/src/shared/uriTemplate.ts.

Impact

ResourceTemplate routes resource URIs through match(), so a handler receives the encoded string rather than the value the client asked for. Any resource whose template variable contains a space or a non-ASCII character is handed the wrong value, silently.

Prior art I checked

The open uriTemplate PRs — #2633, #2170, #2429, #2216, #2218 — all cover multi-variable or optional matching, and none of them adds a decode call. #1785's title mentioned encoded query parameters, but it closed unmerged and the decoding does not appear in its successors, so this axis looks genuinely open.

Environment

Reproduced on @modelcontextprotocol/sdk 1.30.0 and confirmed present on main.

Happy to open a PR if you assign this to me.

Disclosure, per the org AI policy: I used AI assistance for this investigation and write-up — the differential harness that surfaced it and the drafting of this issue. The finding is reproduced and verified, and I can discuss any part of it.

Start in packages/core-internal/src/shared/uriTemplate.ts at match(), then trace how ResourceTemplate routes resource URIs through it. Use the expand/match examples and the reported value sweep to verify behavior; done means extracted values round-trip as decoded strings, including spaces, reserved characters, percent signs, and non-ASCII text.