fix(sessions): only auto-repair prompts with skill_manage evidence

The repair-prompts detector cleared two legitimate prompts:

- a pin with skills_list/skill_view but no skill_manage and zero skills
  installed: build_skills_system_prompt returns '' and SKILLS_GUIDANCE is
  only emitted with skill_manage, so the healthy prompt has neither marker;
- an exact memory-only pin, which is also a user toolsets=[memory] config;
  the healthy rebuild was re-flagged on every run (not idempotent).

Key the decision on the missing '## Skill Safety' guidance, which is
unconditional when skill_manage is in the pin, and require skill_manage in
the pin. Memory-only rows are now reported as unverifiable; the explicit
SESSION_ID override still clears them and their pin.

Docs: describe the tightened rule and note that a running gateway keeps
cached prompts in memory, so it must be restarted after --apply.

website/docs/reference/cli-commands.md

@@ -1760,7 +1760,7 @@ Subcommands:
 | `optimize-storage` | Migrate the full-text search index to the compact v23 external-content layout; on large databases this reclaims a large fraction of `state.db`. |
 | `repair` | Repair a malformed `state.db` schema (e.g. `table messages_fts already exists`) so hidden sessions reappear; a backup is made first. |
 | `repair-routing` | Re-attach gateway conversations stranded in session rows that lost their routing identity (a chat "jumping back in time" after a restart). Dry-run by default; `--apply` performs the adoptions (stop the gateway first); `--max-gap-seconds N` tunes the contiguity window. Only unambiguous cases are repaired. See [Sessions → Repair Stranded Gateway Sessions](../user-guide/sessions.md#repair-stranded-gateway-sessions). |
-| `repair-prompts` | Report stored system prompts provably degraded by the pre-#122822 maintenance-compaction bug. Report-only by default; `--apply` clears verified rows so the next turn rebuilds them, `--json` is machine-readable (and non-interactive when combined with `--apply`), and an explicit `session_id` is a destructive override that can clear even a healthy prompt. Rows without a readable tools[] pin are reported as unverifiable and never auto-repaired. See [Sessions → Repair Degraded Stored Prompts](../user-guide/sessions.md#repair-degraded-stored-prompts). |
+| `repair-prompts` | Report stored system prompts provably degraded by the pre-#122822 maintenance-compaction bug. Report-only by default; `--apply` clears verified rows so the next turn rebuilds them, `--json` is machine-readable (and non-interactive when combined with `--apply`), and an explicit `session_id` is a destructive override that can clear even a healthy prompt. Rows without a readable tools[] pin, or with a memory-only pin, are reported as unverifiable and never auto-repaired. Restart a running gateway after `--apply` so repaired rows take effect. See [Sessions → Repair Degraded Stored Prompts](../user-guide/sessions.md#repair-degraded-stored-prompts). |
 | `repair-profiles` | Settle session, routing, Telegram-topic and voice-mode state that landed under the wrong profile (rows in another profile's store, labels disagreeing with the session key, parent links crossing profiles, index rows for deleted profiles). Dry-run by default; `--apply` performs the repairs after snapshotting every store (stop the gateway first); `--legacy-main rekey\|move` decides what `agent:main` rows inside a named profile's store are; `--json` for automation. See [Sessions → Repair State Crossed Between Profiles](../user-guide/sessions.md#repair-state-crossed-between-profiles). |
 | `recover` | Offline, non-destructive recovery of a damaged `state.db` into a separate clean database. |
 | `retitle-skills` | Regenerate titles for sessions opened with a `/skill`, using what the user actually typed; lists changes unless `--apply` is passed. |

website/docs/user-guide/sessions.md

@@ -666,10 +666,11 @@ live session. After the root fix in PR #122825 is installed, use
 `hermes sessions repair-prompts` to find rows that were already degraded.
 
 The scan is conservative: it only proposes a repair when the stored prompt is
-missing the skills markers **and** the persisted `tools[]` pin proves either
-that skill tools belonged to the session or that the pin is exactly the
-maintenance `memory`-only surface. Older or malformed rows with no readable
-pin are reported as **unverifiable** and are never changed automatically.
+missing the `## Skill Safety` guidance **and** the persisted `tools[]` pin
+contains `skill_manage` (which always emits that guidance). Rows with no
+readable pin, or with a `memory`-only pin (which is also a legitimate
+`toolsets: [memory]` setup), are reported as **unverifiable** and are never
+changed automatically; clear them explicitly by `SESSION_ID` if needed.
 
 ```bash
 # Report verified candidates and unverifiable rows; writes nothing
@@ -689,8 +690,8 @@ hermes sessions repair-prompts --apply --json
 hermes sessions repair-prompts SESSION_ID --apply
 ```
 
-A verified memory-only `tools[]` pin is cleared together with the prompt so
-the next live turn can pin the real surface again. Clearing the prompt
+With an explicit `SESSION_ID`, a memory-only `tools[]` pin is cleared together
+with the prompt so the next live turn can pin the real surface again. Clearing the prompt
 intentionally stores NULL; the next turn rebuilds and persists healthy bytes,
 which causes one expected
 `Stored system prompt ... is null; rebuilding from scratch` warning for each
@@ -700,6 +701,10 @@ evidence of a new corruption.
 Run the repair only after the #122822 root fix is present; otherwise a later
 maintenance compaction can degrade the row again.
 
+A running gateway keeps each cached session's old prompt in memory, so restart
+the gateway after `--apply` (`hermes gateway restart`) for repaired rows to
+take effect.
+
 ### Repair State Crossed Between Profiles
 
 Every profile owns one `state.db`, and every gateway session key names the