fix(gateway): /status reads token totals from SessionDB

[Tranquil-Flow]

Summary

• /status was reading session_entry.total_tokens, which is never updated after the token-persistence refactor (commit 20441cf) — real usage lives in SessionDB (SQLite)
• Adds get_session_token_totals() helper to hermes_state.py that reads aggregated token counts from SessionDB
• /status now prefers SessionDB totals and falls back to session_entry.total_tokens when the DB row is missing
• Corrects None-handling so missing rows don't raise, they fall back cleanly

Fixes #5960.

Files changed

• hermes_state.py — get_session_token_totals() helper + None-row fallback fix
• gateway/run.py — /status wired to use the new helper
• tests/gateway/test_status_command.py — tests for SessionDB-preferred totals and session_store fallback
• tests/test_hermes_state.py — unit tests for token aggregation and missing-row None behavior

Test plan

• pytest tests/gateway/test_status_command.py tests/test_hermes_state.py passes
• /status on a live session reports correct cumulative token counts
• /status with no SessionDB row (fresh install / DB unavailable) falls back without error

[blasai1739217-cmyk]

Friendly bump on this PR in case it fell through the cracks \u2014 would love a review when someone has a minute. Thanks!

[malaiwah]

We tested this approach on a downstream fork that had carried a parallel "fix" for the same symptom — a fork-local commit had reintroduced the gateway-side accumulator pattern that 20441cf2 deliberately removed, and then layered a _lifetime_mirror delta-tracker on top to paper over the resulting quadratic blowup. Both the original fork commit and the band-aid were doing the wrong thing in the wrong layer.

We've now reverted both and adopted this PR's diff as-is (gitea PR + merge: see commit summary below). The result on a real production session that had been showing Tokens: 0 for ~12 hours of agent traffic:

Session ID: 20260409_113641_3e20c9f2
Tokens: 50,409,258
  input_tokens:    1,407,005
  output_tokens:     100,493
  cache_read_tokens: 48,901,760

get_session_token_totals reads from SessionDB cleanly, the total_tokens aggregation matches the agent's lifetime counters, and the SessionStore-fallback path is exercised correctly when the DB row is missing (we tested by clearing the persisted entry). All 202 tests in tests/test_hermes_state.py tests/gateway/test_status_command.py tests/gateway/test_session.py pass with the diff applied.

Strong +1 from a production user. This is the architecturally correct fix — /status should always have read from SessionDB once 20441cf2 moved the source of truth there. The fork's accumulator divergence is a cautionary tale of fixing symptoms instead of root causes; this PR deserves to be the canonical resolution of #5960.

One micro-suggestion (non-blocking): the docstring on get_session_token_totals might note that total_tokens includes cache reads/writes, which is what some downstream consumers expect for "tokens used" but might surprise users coming from raw provider billing semantics where cache reads have different costs. Just a comment clarification, not a behavior change.

[Loping151]

I reproduced this on a live Feishu gateway session as well.

Observed behavior before the fix:

• token usage in the TUI was increasing normally during the same conversation
• but /status in Feishu reported Tokens: 0

So this does not look like Feishu losing usage data. It matches the root cause described here: /status was reading stale SessionStore / session_entry.total_tokens state, while the real token counts were already present in SessionDB / SQLite.

I verified the affected session locally:

• session_entry.total_tokens stayed at 0
• the same session_id in state.db had large non-zero values for input_tokens and output_tokens

After applying the fix, /status in Feishu started reporting the correct cumulative token count for the same session.

So from my side, this PR’s diagnosis and fix direction are correct.

[malaiwah]

PR #8355 includes get_session_token_totals() from this PR as part of a broader /status overhaul. We tested this approach on our downstream fork (as noted in our earlier comment) and it's been solid in production. Credit to @blasai1739217-cmyk for the original fix.

[alt-glitch]

Related to #13820 and #12565 (same fix for #5960). Likely superseded by #8355 which provides a richer /status implementation.

[teknium1]

Fixed on main in 7abc9ce via #17158 — same Camp A approach you proposed (read from SessionDB at display time instead of mirroring into SessionStore). Your PR was submitted first and architecturally correct. Thanks for the thorough fix + state-db regression tests; sorry we didn't land yours directly.