fix: isolate cron approval context

[HeyClaw123]

Summary

• move the cron approval marker into session contextvars instead of process-global os.environ
• make approval guards use the context-local cron marker so gateway sessions are not poisoned by stale HERMES_CRON_SESSION
• add regression coverage for live Discord/gateway approval flows with a stale process-level cron flag, while preserving cron cron_mode behavior

Test plan

• python -m pytest tests/gateway/test_session_env.py tests/tools/test_cron_approval_mode.py tests/tools/test_execute_code_approval_cluster.py tests/tools/test_approval.py::TestApprovalTimeoutIsNotConsent tests/cron/test_cron_script.py tests/cron/test_scheduler.py -q

Context

In a long-lived gateway process, cron scheduler ticks could leave HERMES_CRON_SESSION=1 in process-global environment. Later live Discord/Telegram sessions in the same process could then be misclassified as cron and get cron-only approval behavior, e.g. execute_code being blocked with “Cron jobs run without a user present...” even though a live gateway user was present. This keeps the cron safety default intact while preventing that marker from leaking across sessions.

[alt-glitch]

Competing with #31184 — same core fix (move HERMES_CRON_SESSION from os.environ to contextvars). This PR also adds gateway session hygiene and broader regression test coverage.

[teknium1]

Thanks for isolating a real process-global approval leak. Current main still writes HERMES_CRON_SESSION globally at cron/scheduler.py:2688, and the approval layer still consumes it before gateway classification at tools/approval.py:194 and in the execute-code guard at tools/approval.py:3019.

Problems

• This branch is based on 1044d9f25d63b48c51fe40af0a4cfeea3b6de516; current main has substantially changed all touched files, including the session-context lifecycle and approval implementation. This needs manual salvage rather than a clean cherry-pick.
• The regression coverage does not exercise the scheduler's real contextvars.copy_context() worker handoff at cron/scheduler.py:3138-3139, where the cron marker must survive into agent.run_conversation.

Suggested changes

• During salvage, add a scheduler-worker regression proving that cron retains cron_mode in the copied worker context while a concurrent gateway context is not classified as cron.

This is an automated hermes-sweeper review.

[teknium1]

Please add a regression through the scheduler's copied worker context as well: current main submits contextvars.copy_context().run(agent.run_conversation, prompt) at cron/scheduler.py:3138-3139, so the cron marker must survive that hop without appearing in a concurrent live gateway context.