fix(skills): accept any URI scheme, and stop rewriting the one we parsed

[panyam]

ParseURI required the scheme be exactly skill, and it sits on the live client path
(ReadSkillManifest, ReadSkillFile, ReadDirectory). A server serving a conforming
catalog under a domain-native scheme was refused outright.

SEP-2640 says the opposite in as many words:

Servers SHOULD use the skill:// URI scheme … A server MAY serve skills under
another scheme native to its domain (for example,
github://owner/repo/skills/refunds/SKILL.md). No scheme is privileged.

and adds that a host MUST NOT conclude a resource is a skill merely because its URI
carries a particular scheme, which is the same rule read from the other side.

So we were enforcing a SHOULD as a MUST. Our own conformance check,
sep-2640-skill-uri-scheme, already grades this a WARNING, which means mcpkit's client
was stricter than mcpkit's own suite and no scenario could have caught it.

The half that would have been worse

Relaxing the parse alone introduces a subtler bug. String, SkillRootURI and
ManifestURI rebuilt from the Scheme constant rather than from what was parsed, so a
github:// URI came back out as skill://. That is a different resource, one the
server does not serve, and the failure would then surface as a digest mismatch or a
missing resource rather than as anything to do with schemes.

All three now rebuild from the parsed scheme, with a fallback to the constant for a
URIParts assembled by hand rather than parsed.

What did not change

Every structural rule still applies, to every scheme: traversal segments, empty
segments, SKILL.md placement, and the Agent Skills name grammar on the final
skill-path segment. TestParseURI_SchemeAgnostic_StillStructural pins that, so the
relaxation cannot quietly become a laxer parse.

What is newly rejected is a URI carrying no scheme at all. That is a relative reference,
and it belongs to ResolveRelative rather than here. ErrInvalidScheme keeps its name
so errors.Is callers are unaffected, but its message and doc now say what it actually
means.

Server-side construction is untouched and still emits skill://, which is the SHOULD.

Tests

• TestParseURI_SchemeAgnostic — skill, github, https and a custom scheme all
  parse, and String/SkillRootURI/ManifestURI round-trip without rewriting
• TestParseURI_SchemeAgnostic_StillStructural — traversal, empty segment, manifest-as-
  directory and a bad name all still fail under github://
• TestResolveRelative_PreservesScheme — a relative reference inside a github:// skill
  stays in that skill
• Two existing cases asserted the old behaviour and encoded the bug; they are now a
  relative reference and a scheme-relative URI, which are the things that should fail

make test and the ext/skills suite are green.

Provenance

Noticed while reading the MCP Inspector's SEP-2640 writeup for Inspector 2.6.0, which
grades the scheme as deliberately unconstrained and reaches the same reading
independently.