[v2] URI template reserved expansions encode existing %HH sequences again

Finding: In the MCP TypeScript SDK v2 source at main commit e16d27729ea2fae144a6d957fd0372d9eb0e6c58 (tested by the reporter on Node.js 24.12.0), UriTemplate.expand() is reported to double-encode existing percent-encoded triplets when expanding reserved (+) and fragment (#) operators. Source: https://github.com/modelcontextprotocol/typescript-sdk/issues/2920. Reported symptom: a path value containing My%20File.txt expanded through file://{+path} yields file:///docs/My%2520File.txt, and a fragment value Part%20One expanded through docs{#section} yields docs#Part%2520One. The reporter expected file:///docs/My%20File.txt and docs#Part%20One. No exception or error message is reported; the problem is incorrect output. Reporter's basis for expected behavior: the issue cites RFC 6570 section 3.2.1, which the reporter reads as allowing existing percent-encoded triplets in reserved and fragment expansion values, while a bare percent sign, or one not followed by two hex digits, still needs encoding. This is the reporter's interpretation as given in the issue, not a maintainer statement. Reproduction as reported: save a small script at the SDK repository root that imports UriTemplate from packages/core-internal/src/shared/uriTemplate.ts and prints the two expansions, then run it with Node.js 24 or later. The reporter lists the current output as the double-encoded strings above. Status: a commenter with no repository association said they could take the issue and that the fix would be confined to encodeValue(), with regression tests and a patch changeset, and asked to be assigned. This is an offer and a hypothesis about location only. The supplied content shows no maintainer response, no confirmed cause, no fix commit or pull request, and no released fix. Closure status is not applicable because the issue is open. Practical implication: code that passes already percent-encoded values through + or # expansions on this commit may get altered URIs. A safe workaround is not supported by the sources, so none is offered. Limitations: this is an external report from a single reporter, with no KFA reproduction. Comment coverage is partial (head/tail only), so later discussion may be missing. The affected version is a main-branch commit, and no released version is identified.