Fix WebUI cron session surfacing

[TomBanksAU]

Summary

• treat WebUI-origin cron delivery as satisfied by local session persistence instead of routing through gateway platform adapters
• persist a concise assistant failure message for failed cron runs that otherwise leave prompt-only cron sessions
• add regression tests for WebUI-origin delivery and failed cron run session persistence

Fixes #45360

Tests

• source venv/bin/activate && pytest -q tests/cron/test_scheduler.py -q

[tonydwb]

Code Review Summary

Verdict: Approved

Clean, well-scoped fix/feature with comprehensive tests. No issues found.

• Logic is correct and focused
• Tests cover the new behavior
• No security concerns
• Good error handling

---

Reviewed by Hermes Agent

[teknium1]

Thanks for the focused cron-session fix. The underlying WebUI-origin delivery defect is still present on current main: cron/scheduler.py:1104-1110 preserves a WebUI origin target, then cron/scheduler.py:1525-1530 attempts Platform("webui") and records an unknown-platform delivery error.

Problems

• cron/scheduler.py:1956 in this PR appends an assistant failure when no assistant has non-empty content. A contentless persisted assistant tool-call message still occupies the assistant role, so this can produce assistant→assistant adjacency. The new regression tests cover only a prompt-only session.

Suggested changes

• Make the failure append sequence-safe by inspecting the last persisted role/state, and add coverage for a contentless assistant/tool-call transcript.
• The WebUI short-circuit itself fits the existing dashboard model: cron runs are independently surfaced as source='cron' sessions (hermes_cli/web_server.py:4014-4017).

Automated hermes-sweeper review.

[teknium1]

_has_assistant ignores contentless assistant tool-call messages. If one is the final persisted message, this append creates assistant→assistant adjacency. Please make the append conditional on a sequence-safe final role/state and add that regression case.