feat: Adding "skill" server adapter in spec and engine

[jlouvel]

Introduces the skill server adapter, which exposes one or more AI agent skill definitions over HTTP, making them discoverable and downloadable by agents and tooling.

Spec layer:

• ExposedSkillSpec — skill definition (name, description, tools, location, metadata, compatibility flags)
• SkillToolSpec / SkillToolFromSpec — tool declarations (derived from capability actions or standalone instructions)
• SkillServerSpec — groups skills under a shared base path and port
• ServerSpec wired to accept skill adapter type

Engine layer:

• SkillServerAdapter — wires Restlet Router + Server with five routes and starts the HTTP listener
• SkillServerResource (abstract) — shared base with path-traversal validation, MetadataService-based MIME detection, and a shared ObjectMapper
• SkillCatalogResource — GET /skills
• SkillDetailResource — GET /skills/{name}
• SkillContentsResource — GET /skills/{name}/contents
• SkillFileResource — GET /skills/{name}/files/{file} (streaming via FileRepresentation)
• SkillDownloadResource — GET /skills/{name}/download (ZIP via OutputRepresentation)

All JSON responses use JacksonRepresentation<ObjectNode> (no in-memory string serialization).

Schema: ExposesSkill, ExposedSkill, SkillTool added to
capability-schema.json.

Docs: §§3.5.9–3.5.12 added to naftiko-specification-v0.5.md;
skill-adapter.yml example added.

Tests: 27 new tests across CapabilitySkillIntegrationTest,
SkillServerSpecRoundTripTest, and SkillToolSpecDeserializationTest.

[eskenazit]

This is confusing ^^' We have a Notion specification page, a PR with the wiki specification with request fir change and a PR with an implentation fo the spec. I do not know against which specification I am supposed to use to validate this PR... Let us discuss process before moving on =)

[jlouvel]

The wiki PR was created before the work on this implementation started, hence the disconnect. I will refresh it.

For the scope of this PR, the included spec (agent-skills-support-proposal.md) is exactly the same as the spec in Notion that you reviewed. So this implementation is consistent with it.

[eskenazit]

LGTM

[eskenazit]

@jlouvel I cannot rebase and merge due to conflicts, I let you handle that =)

[jlouvel]

@eskenazit Ok, I think I resolve the conflicts properly. Note that I moved the specification-v0.4.md and specification-v0.5.md files into the Wiki folder and deleted the Specs folder for consistency (we have Specification.md published in the wiki already). Could you double check that I have your latest version there?

Also, when this is merged, we should sync the published wiki page so it has v0.5 as well:
https://github.com/naftiko/framework/wiki/Specification

[eskenazit]

@jlouvel I disagree we should sync when it is merged. The wiki should reflect the latest release, so we should update the wiki when we release the 0.5, should we not ?

[jlouvel]

@eskenazit Yes, you are right. What I wanted to convey is the goal of this Wiki folder to represent the intended state of the published wiki. But that needs to respect the release life cycle

[eskenazit]

@jlouvel I think I fixed the missing skills part, I now let you fix conflicts created by the rename of the schema =)

[jlouvel]

Thanks @eskenazit ! I've rebased and updated all the Naftiko YAML files to point to naftiko-schema.json

[eskenazit]

LGTM