fix(cron): keep approval context task-local

[adambiggs]

Summary

• make HERMES_CRON_SESSION task-local via the existing gateway ContextVar session state
• stop run_job() from permanently mutating the gateway process environment
• make all approval gates resolve cron status through the context-local marker

Bug

The cron scheduler runs inside the long-lived messaging gateway, but run_job() sets:

os.environ["HERMES_CRON_SESSION"] = "1"

and never clears it. After the first scheduled job, later interactive Telegram turns are classified as cron. In a live DM, execute_code consequently returned:

BLOCKED: ... Cron jobs run without a user present to approve it.

instead of routing through the interactive approval flow.

Verification

scripts/run_tests.sh \
  tests/gateway/test_session_env.py \
  tests/tools/test_cron_approval_mode.py \
  tests/tools/test_execute_code_approval_cluster.py \
  tests/tools/test_request_tool_approval.py \
  tests/cron/test_scheduler.py -q

301 passed

The scheduler test also asserts that cron context is visible during the agent turn while os.environ remains untouched, and that cleanup removes the task-local marker.

[alt-glitch]

This was generated by AI during triage.

Duplicate of #58663 — same mechanism and same three source files (cron/scheduler.py, gateway/session_context.py, tools/approval.py): replace the process-global os.environ["HERMES_CRON_SESSION"]="1" with a per-job _CRON_SESSION ContextVar so interactive gateway turns stop being misclassified as cron. #58663 is the earliest open PR with this fix (canonical). Also related to #56796 (competing ContextVar approach). Flagging for a human to pick the canonical.

[adambiggs]

Closing as a duplicate of #58663. I should have searched open PRs before opening this; #58663 already fixes the same process-global HERMES_CRON_SESSION leak and has stronger reset-token coverage. Sorry for the duplicate noise.