Feature request: Hermes Agent session monitoring (hardened design, revisit #139)

**Feature request: Hermes Agent session monitoring (revisit after #139)**

[Hermes Agent](https://github.com/NousResearch/hermes-agent) by Nous Research is an open-source AI agent framework in the same category as Claude Code / Codex CLI / OpenCode (local TUI + gateway, per-session token accounting, model-agnostic). It is widely deployed in terminal and desktop workflows, and its sessions are fully discoverable from local process + SQLite state — exactly abtop's model.

A previous attempt, PR #139 ("feat: add Hermes Agent session collector"), was closed with security feedback: it generated Python source with interpolated DB paths/session IDs, stored transcript text (initial prompts, assistant text, tool-call args) without the collector redaction model, and wrote predictable temp SQL files. I agree with all of that feedback — this issue proposes a smaller, hardened design that addresses each point:

- **No dynamic code generation, no external interpreter, no temp files.** Read `~/.hermes/state.db` (or `HERMES_HOME`) read-only in-process via `rusqlite` (bundled SQLite) — same privacy posture as the existing collectors, zero shell surface, works on macOS/Linux/Windows without requiring a `sqlite3`/Python install.
- **Process discovery without string interpolation.** Hermes runs one `tui_gateway.slash_worker --session-key ` process per active session; matching is done by parsing already-scanned process command lines (the same `SharedProcessData` the other collectors use), never by building scripts.
- **Follow the existing privacy/redaction model from the start.** Every DB-sourced string (title, cwd, chat tail, tool args) goes through `sanitize_terminal_text` → `redact_secrets` → truncation, exactly like the OpenCode/Claude collectors.
- **No symlink-following, fail-closed** on the DB path, readonly connection only, results cached on the slow tick like `OpenCodeCollector`.

Scope would be the same feature set as the table in #139: session discovery, token tracking (input/output/cache from the `sessions` table), status detection, context-window % (model lookup table), child processes, git status. Rate limits are N/A (Hermes doesn't expose them).

Happy to open a PR implementing this design — just want to confirm the direction (in-process `rusqlite` vs. staying on the `sqlite3`-CLI pattern) before writing it.

Start by reviewing the existing OpenCode and Claude collectors, SharedProcessData process parsing, and OpenCodeCollector's slow-tick caching. Then inspect Hermes' ~/.hermes/state.db or HERMES_HOME schema and confirm the in-process rusqlite direction; done means session discovery, token and context tracking, status, child processes, and git status follow the stated redaction and fail-closed rules.

Written by the indexing model from the issue text.