Add thv skill builds command to list locally-built OCI artifacts

[samuv]

Summary

thv skill build packages a skill directory into a local OCI artifact, but there was no way to see what had been built. This adds a thv skill builds command (and backing API endpoint) to list locally-built OCI skill artifacts stored in the local OCI Image Layout.

• New LocalBuild type carrying tag, digest, name, description, and version
• New ListBuilds method on SkillService reading tags from the local OCI store, filtering to skill artifacts by ArtifactType == "dev.toolhive.skills.v1", and best-effort enriching them with skill config metadata from OCI image labels
• New GET /api/v1beta/skills/builds API endpoint returning {"builds": [...]}
• New thv skill builds CLI command with --format json|text support
• Fix task docs to exclude pkg/mod and pkg/sumdb from swag's file scan

Type of change

• New feature

Changes

File	Change
pkg/skills/options.go	Add LocalBuild type
pkg/skills/service.go	Add ListBuilds to SkillService interface
pkg/skills/skillsvc/skillsvc.go	Implement ListBuilds with ArtifactType filter and best-effort metadata
pkg/skills/skillsvc/skillsvc_test.go	7 unit tests for ListBuilds including ArtifactType filtering
pkg/skills/mocks/mock_service.go	Regenerated mock
pkg/api/v1/skills.go + skills_types.go	GET /api/v1beta/skills/builds handler and response type
pkg/api/v1/skills_test.go	3 router tests for the new endpoint
pkg/skills/client/client.go + dto.go	ListBuilds HTTP client method
cmd/thv/app/skill_builds.go	thv skill builds CLI command
docs/server/	Regenerated OpenAPI spec
Taskfile.yml	Add --exclude pkg/mod,pkg/sumdb to swag init

Does this introduce a user-facing change?

Yes. Users can now run thv skill builds to see all locally-built skill artifacts with their tag, digest, name, and version. The same data is available via GET /api/v1beta/skills/builds.

Special notes for reviewers

ListBuilds filters the tag list by ArtifactType == "dev.toolhive.skills.v1" (the same value the packager sets at build time) so that remotely-pulled or non-skill artifacts sharing the local OCI store are not surfaced. Metadata extraction (name, description, version) is still best-effort: if the OCI config labels can't be parsed the artifact is included with those fields empty.

[codecov]

Codecov Report

❌ Patch coverage is 58.06452% with 26 lines in your changes missing coverage. Please review.
✅ Project coverage is 68.90%. Comparing base (4bb35be) to head (91ea982).

Files with missing lines	Patch %	Lines
pkg/skills/skillsvc/skillsvc.go	60.41%	14 Missing and 5 partials ⚠️
pkg/skills/client/client.go	0.00%	5 Missing ⚠️
pkg/api/v1/skills.go	77.77%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4499      +/-   ##
==========================================
+ Coverage   68.83%   68.90%   +0.06%     
==========================================
  Files         505      505              
  Lines       52437    52499      +62     
==========================================
+ Hits        36095    36172      +77     
+ Misses      13550    13533      -17     
- Partials     2792     2794       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[JAORMX]

The ListBuilds implementation lists every tag in the OCI store, but the store also holds pulled/installed skills from remote registries... not just local builds. We should filter using the ArtifactType field we already set at build time (dev.toolhive.skills.v1) to make sure we're only returning what we intend to return.

See inline comment for details.