feat: Phase 1 skill registry and management CLI

[dahifi]

Skill Registry — Phase 1

Adds a skill catalog and CLI for managing skill distribution to hatchlings.

What's in

• registry/registry.json — 10 platform skills cataloged (tier, version, deps)
• registry/skills/ — each skill with OC-format SKILL.md + executable scripts
• scripts/skills.sh — CLI: list, status, install, push, remove
• scripts/test-skills.sh — 17 tests passing
• docs/SKILL-REGISTRY-SPEC.md — full architecture spec (Phase 1-3)

Skills cataloged

ask-sook, bus-publish, bus-heartbeat, bus-command-handler, bus-command-handler-keepalive, kokoro, print-doc, resend, stitch, transcribe-voice

Key design decisions

• Docker env vars from environment or fleet.json (no hardcoded infrastructure)
• Mock mode (SKILLS_MOCK_ROOT) for testing without Docker
• OC skill format preserved (YAML frontmatter SKILL.md)
• Skills deploy to workspace volumes (survive container rebuilds)

Phase 2 (follow-up)

• Wire hatch.sh to auto-install platform skills
• Wire fleet.sh update to push skill updates
• Add diff and manifest commands

[dahifi]

🜁 Zephyr Review — PR #26: Phase 1 Skill Registry

Overall: Solid foundation. Clean implementation with good test coverage.

✅ What's good

• Spec doc is thorough — clear tier definitions (platform/client/private), install semantics, migration phases. This is how we should design features.
• skills.sh is well-structured — mock mode for testing without Docker is smart. Docker env resolution from fleet.json is exactly right for our NAS setup.
• Test suite covers the core loop — registry validation, list/install/remove in mock mode, manifest tracking. 8 tests, all meaningful.
• No hardcoded infra — MQTT defaults to Docker DNS (mosquitto), no IPs or hostnames baked in.
• Registry JSON is accurate — correctly catalogs our current platform skills (bus-*, kokoro, resend, stitch, etc.)

📝 Minor notes (non-blocking)

1. ask-sook naming — The skill references "Sook" as the parent agent. This is fine as a generic name for the registry, but deployments will need to know this means "escalate to parent." Consider a comment in SKILL.md noting the name is configurable per fleet.
2. bus-command-handler-keepalive — The restart-via-cron approach works but is a bit fragile. Phase 2 could use a proper process supervisor (s6, tini). Not blocking for Phase 1.
3. E2E CI failure is the pre-existing container health check timeout (needs API key not available in CI) — not caused by this PR.

🔧 Suggestion for follow-up

• Wire hatch.sh --skills integration (Phase 2 in the spec) as a separate PR to keep this one clean.

Verdict: Ready to merge once Michael approves. The spec is sound, the implementation matches, and tests pass.