feat(providers): add Hermes Agent provider

[franciskwan]

Summary

Adds a new lazy-loaded hermes provider that reads Hermes Agent session files from ~/.hermes/sessions/ and surfaces them in the codeburn dashboard, alongside the 20+ existing providers.

Hermes Agent (https://hermes-agent.nousresearch.com) is a CLI coding agent similar in spirit to Claude Code, Codex CLI, etc. It writes JSON session transcripts to ~/.hermes/sessions/, but did not have a codeburn provider, so its usage was invisible to the dashboard.

What it surfaces (verified on 9 real sessions)

• Session count, model identity, daily/weekly/monthly activity
• Per-session tool-call frequency and tool-name distribution (Read, Bash, WebFetch, Write, …)
• Bash command extraction from terminal tool calls (so the "Shell Commands" panel works)
• Activity classification (Conversation / Coding / Feature Dev / Exploration / …) via the existing auto-classifier, fed by extracted user prompts
• Split between foreground (session_*.json) and background (session_bg_*.json) sessions as separate projects

What it does NOT surface (and why)

• Per-turn token usage. Hermes does not persist usage blocks locally — only the conversation transcript is in ~/.hermes/sessions/. Token counts live on the upstream provider (OpenAI / Anthropic / OpenRouter / Ollama). The Token and Cost columns therefore show 0 with costIsEstimated: true; users wanting real spend are pointed at upstream provider dashboards.
• request_dump_*.json files. Those are captured failed HTTP requests, not conversations. Including them would skew the dashboard with error noise. Skipped intentionally.

Implementation notes

• Mirrors the existing lazy-load pattern in src/providers/index.ts (see loadForge, loadVercelGateway), so users without ~/.hermes/ installed don't get a startup crash.
• The request_dump_*.json skip is also a privacy choice — those files can contain captured upstream request bodies.
• Tool-name mapping translates Hermes' tool inventory (terminal, read_file, browser_navigate, …) into codeburn's display categories (Bash, Read, WebFetch, …) using the same pattern as the openclaw provider.
• calculateCost is still called with the session's model field, so any Hermes model that happens to be in litellm-snapshot.json or pricing-fallback.json (e.g. hermes-4-70b is already in the fallback table as of v0.9.12) will get a real cost figure; everything else is $0 with the standard costIsEstimated warning under CODEBURN_VERBOSE=1.

Verification

End-to-end smoke test against a real ~/.hermes/sessions/ directory with 9 sessions spanning 3 dates and 3 models:

npm install
npm run build

# TUI shows populated panels for By Model, By Project, Core Tools, Shell Commands
node dist/main.js report --period 30days --provider hermes --format tui

# JSON export returns real data
node dist/main.js report --period all --provider hermes --format json | jq '.overview'
# → {"cost": 0, "calls": 9, "sessions": 9, "tokens": {…}, ...}

No regressions to existing providers — verified by the project's own vitest suite and by re-running the dashboard with --provider all.

Files

• NEW src/providers/hermes.ts (318 lines, mirrors the openclaw provider pattern)
• MODIFIED src/providers/index.ts (3 small additions: loadHermes() lazy loader, registration in getAllProviders(), branch in getProvider('hermes'))

Total: 320 insertions, 2 deletions across 2 files.

Open questions for maintainer

1. Is the lazy-load pattern (separate file + dynamic import()) the preferred shape for new providers, or would you prefer a coreProviders static import? (I followed the lazy pattern since openclaw/warp/forge/vercel-gateway do the same.)
2. The hermes-background project name is arbitrary — happy to rename to hermes-bg or fold it into the main hermes project if you have a convention.
3. Should the hermes provider be wired up for MCP exposure (mcp command), or is that gated until the upstream usage story improves?