Clarify non-exploded list matching in URI-template documentation and tests #3861

Would you welcome a documentation-and-tests-only contribution clarifying the difference between list expansion and inverse matching?

During source-based investigation on main at 77001c96, I observed:

from mcp.shared.uri_template import UriTemplate

t = UriTemplate.parse("items{/ids}")
uri = t.expand({"ids": ["a", "b"]})

print(uri)                         # items/a,b
print(t.match(uri))                # {'ids': 'a,b'}
print(t.expand(t.match(uri)))      # items/a%2Cb

The simple form items/{ids} does not match its list expansion. The documented exploded form items{/ids*} preserves list boundaries, including an encoded comma within one item.

I am not proposing automatic comma splitting or a runtime change. Matching cannot generally infer whether a comma represents list structure or scalar content, and RFC 6570 specifies expansion rather than a general inverse.

The proposed change would:

• Add a short explanation and examples to docs/servers/uri-templates.md, recommending exploded templates for list-valued handlers.
• Add three tests characterizing current non-exploded matching limits and protecting scalar-comma and exploded-list behavior.
• Clarify that the existing inversion property test generates lists only for exploded variables, so it does not cover every value accepted by expand().

A local patch is prepared; nothing has been submitted. The final version passes all 310 URI-template tests, file-scoped Pyright, Ruff lint and formatting. A preceding candidate passed the full suite: 6,228 passed, 16 skipped and one existing xfail. Global Pyright was not clean on Windows, and documentation build/Markdown lint have not been validated.

This came from synthetic investigation, not a production incident. AI assistance was used for investigation, implementation, testing and drafting.

Would this clarification fit the intended contract? I would wait for agreement on scope and the required issue assignment before opening a PR.