docs(curator): align 'agent-created' definition with actual provenance semantics

The curator docs stated that any skill not bundled/hub-installed was
'agent-created' and subject to curation — including foreground-created
skills and hand-written ones. Since PR #19621 (May 2026), the curator
requires an explicit  marker in .usage.json, which
only the background self-improvement review fork sets.

Changes:
- Rewrite 'What agent-created means' to document the 3-step eligibility
  check (not bundled + not hub + created_by=agent marker)
- Explain that foreground skill_manage(create) does NOT mark skills as
  agent-created (user-directed by design)
- Warn that hand-written skills are NOT curated
- Add note in Per-run reports explaining the '(not resolved)' display
  when no candidates exist (LLM pass skipped, not a config error)
- Link to skill_provenance.py for the write-origin ContextVar

Ref: PR #19621, tools/skill_provenance.py, tools/skill_manager_tool.py

website/docs/user-guide/features/curator.md

@@ -130,30 +130,45 @@ The same subcommands are available as the `/curator` slash command inside a runn
 
 ## What "agent-created" means
 
-A skill is considered agent-created if its name is **not** in:
+The curator only manages skills explicitly marked as **agent-created** in
+`~/.hermes/skills/.usage.json`. A skill qualifies when ALL of the following
+are true:
 
-- `~/.hermes/skills/.bundled_manifest` (skills copied from the repo on install), and
-- `~/.hermes/skills/.hub/lock.json` (skills installed via `hermes skills install`).
+1. Its name is **not** in `~/.hermes/skills/.bundled_manifest` (bundled skills shipped with the repo).
+2. Its name is **not** in `~/.hermes/skills/.hub/lock.json` (hub-installed skills).
+3. Its `.usage.json` entry has `"created_by": "agent"` or `"agent_created": true`.
 
-Everything else in `~/.hermes/skills/` is fair game for the curator. This includes:
+Currently, only the **background self-improvement review fork** sets this marker
+— when it creates a new umbrella skill during its periodic review pass (~every 10
+agent turns). The background fork runs with a write origin of `"background_review"`
+(via `tools/skill_provenance.py`), which is the only path that triggers the
+`mark_agent_created()` call in `skill_manage`.
 
-- Skills the agent saved via `skill_manage(action="create")` during a conversation.
-- Skills you created manually with a hand-written `SKILL.md`.
-- Skills added via external skill directories you've pointed Hermes at.
+Skills the foreground agent creates via `skill_manage(action="create")` during a
+conversation are **not** marked as agent-created — they are considered
+user-directed and the curator intentionally leaves them alone.
 
-:::warning Your hand-written skills look the same as agent-saved ones
-Provenance here is **binary** (bundled/hub vs. everything else). The curator cannot tell a hand-authored skill you rely on for private workflows apart from a skill the self-improvement loop saved mid-session. Both land in the "agent-created" bucket.
+:::warning Your hand-written skills are NOT curated
+If you manually created a `SKILL.md` or pointed Hermes at an external skill
+directory, that skill will have a `.usage.json` entry with `created_by: null`
+(or the field absent). The curator will not touch it. The same applies to
+skills the foreground agent created at your request.
 
-Before the first real pass (7 days after installation by default), take a moment to:
-
-1. Run `hermes curator run --dry-run` to see exactly what the curator would propose.
-2. Use `hermes curator pin <name>` to fence off anything you don't want touched.
-3. Or set `curator.enabled: false` in `config.yaml` if you'd rather manage the library yourself.
-
-Archives are always recoverable via `hermes curator restore <name>`, but it's easier to pin up-front than to chase down a consolidation after the fact.
+**To see which skills the curator actually manages**, run `hermes curator status`.
+If the agent-created count is 0, no skills are currently in the curator's
+jurisdiction — the LLM review pass is skipped and the report will show
+`Model: (not resolved) via (not resolved)` with `Duration: 0s`.
 :::
 
-If you want to protect a specific skill from ever being touched — for example a hand-authored skill you rely on — use `hermes curator pin <name>`. See the next section.
+Skills that ARE agent-created follow the full lifecycle:
+
+- `active` → (30d unused) `stale` → (90d unused) `archived`
+- Pinned skills bypass all auto-transitions
+- Archives are recoverable via `hermes curator restore <name>`
+
+If you want to protect a specific skill from ever being touched — for example a
+hand-authored skill you rely on — use `hermes curator pin <name>`. See the next
+section.
 
 ## Pinning a skill
 
@@ -217,6 +232,15 @@ Every curator run writes a timestamped directory under `~/.hermes/logs/curator/`
 
 `REPORT.md` is a quick way to see what a given run did — which skills transitioned, what the LLM reviewer said, which skills it patched. Good for auditing without having to grep `agent.log`.
 
+:::note No candidates? Report shows `(not resolved)`
+When the curator has **no agent-created skills** to review, the LLM review pass
+is skipped entirely. The report header will show
+`Model: (not resolved) via (not resolved)` with `Duration: 0s` — this does **not**
+indicate a configuration error or model resolution failure. It simply means there
+were no candidates, so no model was ever invoked. The auto-transition phase still
+runs and reports its counts normally.
+:::
+
 ### Rename map in the summary
 
 If a run consolidated multiple skills under an umbrella (or merged near-duplicates), the user-visible summary printed at the end of the run includes an explicit rename map showing every `old-name → new-name` pair the curator applied. This is in addition to per-skill transition lines, so when a wave of renames lands you can spot them at a glance without diffing the JSON report. The hint also surfaces under `hermes curator pin` so you can pin the umbrella name immediately if you want to lock the new label in.