feat(skills): carry cache attributes on skills/get (ext-skills#139)

[panyam]

ext-skills#139 merged today, so the stable spec page now has GetSkillResult extends CacheableResult: ttlMs and cacheScope are REQUIRED on skills/get as they are on resources/read. handleSkillsGet returned a bare {skill}, which made mcpkit non-conforming the moment that landed.

This is a behaviour change, not a clarification

Worth stating plainly, because it affects anyone tracking the SEP rather than the page. SEP-2640 says of these fields that "whether the result should also carry the base protocol's caching attributes … is left open", so a server conformant to the SEP text alone omits both and becomes non-conformant to the page.

It is also a reading not everyone shares. The MCP Inspector's SEP-2640 writeup argues the opposite, that the SEP forecloses the requirement and inventing one would report a reasonable server as broken by the tool whose job is to say whether it conforms. The stable page is what the conformance suite grades against, so mcpkit follows it, but the disagreement is real and worth knowing about.

The answer matches skills/list

Same catalog, so the same freshness answer. A server wanting to hint differently for a single entry than for the listing has no knob yet and nothing has asked for one. The test pins the agreement, because a divergence would tell a host the listing and the entry go stale at different times when they do not.

Neither field is an integrity property: verification against digest and size is unaffected by how fresh a held entry is.

Verification

Negative control recorded. Without the change the new test reports both fields missing and both absent from the result's top level. Upstream, a build with the attributes stripped scores 31/32 on sep-2640-skills-enumeration with sep-2640-skills-get-cache-attributes FAILURE; with the change it is 32/32, and 30/30 on the 2025-11-25 wire where the check SKIPs below the version floor.

make test and the ext/skills suite are green.