feat(curator): user-facing CLI for skill usage stats, archive/restore, and prune

[teknium1]

Summary

Expose the curator's skill-usage data and lifecycle operations via hermes skills subcommands so users can inspect and manage skill health from the CLI.

Motivation

The curator (PR #bc79e227e) already tracks per-skill usage in the skill_usage SQLite table and performs background maintenance. Users currently have no direct way to:

• See which skills they actually use vs. which are dead weight
• Manually archive/restore a skill without deleting it
• Prune skills unused for N days on demand

Credit: @fathah's PR #4406 proposed this CLI surface alongside a larger (now-redundant) ranking/tracking rewrite. The ranking/tracking pieces are subsumed by the shipped curator, but the CLI surface is genuinely net-new.

Proposed surface

```
hermes skills stats # per-skill view/invoke counts, last-used, days-idle
hermes skills archive # move skill to archived/ (excluded from prompt)
hermes skills restore # move back from archived/
hermes skills prune [--days N] # list+confirm removal of skills idle >= N days
```

Notes

• Must integrate with the curator's existing skill_usage table, not introduce a parallel store.
• `archive` should respect pinning (PR feat(skills): refuse skill_manage writes on pinned skills #17562) — pinned skills cannot be archived.
• `prune` must offer a dry-run and explicit confirmation; default `--days` should be conservative (e.g. 90).
• Do NOT add per-message keyword-relevance ranking to the system prompt — that would invalidate the system prompt cache every turn.

[elmatadorgh]

I'd like to take this. Going to read through the curator code and the old #4406 PR first to get a feel for the scope. Will come back with a few questions before opening a PR, mainly about the archive folder structure, stats output format, and how prune should handle non-interactive use. Should be back within a day.

[elmatadorgh]

Read through fathah's #4406. The CLI scaffolding and tests look reusable, ranking parts I'd drop.

Two things I couldn't find on main:

1. The skill_usage table, only live aggregation I see is in insights.py. Did the curator land somewhere else?

2. feat(skills): refuse skill_manage writes on pinned skills #17562 skill pinning, also can't find it.

If both are still pending, I'd start with stats and prune off insights.py, leave archive/restore for after pinning lands. Easier to review in pieces. Open to one big PR if you'd rather.

[elmatadorgh]

Correction on my last comment, my bad. Looked again with a fresh checkout of main and both pieces are in fact merged: curator at bc79e22, pinning at #17562 (c61b2e0). I was grepping a stale branch. The skill_usage data lives in tools/skill_usage.py on main, not a SQLite table, but it's there.

So scope is closer to what you originally said. Going to read through tools/skill_usage.py and how skill_manage exposes archive/restore today, then come back with a concrete plan.