fix(cron): don't let a cron job inherit a kanban worker's dispatcher identity

[kshitijk4poor]

Summary

A kanban worker that fires a cron job in-process no longer leaks its task identity into the cron agent — so an unrelated cron job can no longer call kanban_complete on the worker's task and overwrite real results.

Salvages the intent of #78961 (@gfriesen1 spotted the symptom and the exact gating mechanism), with a corrected root-cause mechanism and a ContextVar instead of an os.environ mutation.

Context — what actually goes wrong, concretely

Who is affected: anyone running the kanban dispatcher in a gateway process where a worker also fires cron jobs.

When: a kanban worker is a normal hermes chat -q CLI agent, and its default toolset includes cronjob (toolsets.py:72). It runs with HERMES_KANBAN_TASK legitimately set in its own environment. If that worker calls cronjob(action="run"), tools/cronjob_tools.py:688 calls run_one_job() → run_job() in that same process.

Why it matters: the cron AIAgent is then constructed while the worker's kanban vars are visible, so it is misidentified as that worker:

Signal	Clean cron session	Cron fired from a worker (before)
kanban env active (_detect_environment)	False	True
kanban_show gated on (_check_kanban_mode)	False	True
kanban_complete default task_id	None	t_worker_real_task

The last row is the damage: kanban_complete defaults task_id to $HERMES_KANBAN_TASK (tools/kanban_tools.py:137,1110), so a cron agent that decides to tidy up closes the worker's task and overwrites its results.

Why a ContextVar and not an os.environ clear

The obvious fix — clear the vars around agent construction — is wrong, because os.environ is process-global and three concurrent readers legitimately need the real values. Each of these was verified, and two were reproduced:

1. It starves the worker's own claim heartbeat. run_agent.py:3695 _touch_activity does if os.environ.get("HERMES_KANBAN_TASK"): heartbeat_current_worker_from_env(), which reads TASK/CLAIM_LOCK/RUN_ID (kanban_tools.py:286,297,302). The cron-run heartbeat thread drives that every 10s (cronjob_tools.py:658). Clear the vars and the heartbeat silently no-ops; after DEFAULT_CLAIM_TTL_SECONDS = 15 min (kanban_db.py:219) the dispatcher reclaims a task whose worker is still alive and re-dispatches it — the same duplicate-work/overwrite failure, arriving from the other direction.
2. Concurrent cron jobs destroy the identity permanently. Workdir-less jobs run on the parallel pool and take a shared read lock (scheduler.py:3156 acquire_read), so they interleave: A clears → B snapshots {} → A restores → B clears → B's restore is a no-op. Reproduced: HERMES_KANBAN_TASK and BOARD both end up None.
3. It races the gateway's own watcher. gateway/kanban_watchers.py:1369-1417 pins HERMES_KANBAN_BOARD across a slow decompose_task() LLM call, and the decomposer takes no board argument (kanban_decompose.py:271,459) — it resolves from the env var. Reproduced: pinned team-alpha → resolved default, i.e. child tasks written to the wrong board's DB.

A ContextVar is per-thread, invisible to those readers, and propagates into the agent thread for free via the contextvars.copy_context() already at scheduler.py:3581.

Divergence from #78961

#78961 attributed the leak to the dispatcher writing into the gateway's environment, and fixed it with an unconditional, unrestored os.environ.pop() of 6 vars. Verifying that premise changed both the diagnosis and the fix:

• The dispatcher never mutates the parent env. _default_spawn builds a copy — hermes_cli/kanban_db.py:8991 env = dict(os.environ) — passed to subprocess; AST inspection shows zero os.environ mutations in the function. A repo-wide grep for in-process writes of HERMES_KANBAN_* returns exactly two, neither the dispatcher: gateway/kanban_watchers.py:1371 and hermes_cli/main.py:2460 (both BOARD). So TASK/WORKSPACE/DB/RUN_ID/CLAIM_LOCK could not leak by that route — and TASK is the var that does the damage. The real route is the in-process cronjob → run_job path above.
• HERMES_KANBAN_BOARD must not be cleared at all. It is a deliberate pin (hermes_cli/main.py::_pin_kanban_board_env, [Bug]: harness kanban CLI invoked from agent session ignores active-board pin, races current file with concurrent boards switch #20074) keeping in-process kanban_* tools and shelled-out hermes kanban calls on one board. This PR leaves BOARD/DB/WORKSPACES_ROOT untouched.

Changes

• agent/delegation_context.py — new non_dispatcher_owned_context() (plus token form for long try/finally scopes) and is_dispatcher_owned_worker_context(), the single predicate every HERMES_KANBAN_* identity gate consults before trusting those vars. Kept separate from the existing delegate_task flag so that behaviour is unchanged.
• cron/scheduler.py — run_job enters that context alongside the existing _cron_session_var token and resets it in the same finally. No env mutation.
• tools/kanban_tools.py — _check_kanban_mode, _check_kanban_orchestrator_mode, and _default_task_id now require dispatcher ownership before honouring HERMES_KANBAN_TASK. An explicit task_id argument is still honoured.
• model_tools.py — the kanban toolset force-add is gated, and the predicate joins _tool_defs_cache's key so contexts don't share a cache entry.
• agent/skill_utils.py — closes a pre-existing gap: it read the vars without consulting the delegate_task ContextVar at all. The kanban verdict also now bypasses _ENV_DETECT_CACHE, since a context-dependent answer must not be memoized process-wide.

Validation

	Before	After
Cron agent inherits worker task id	yes	no
Worker's claim heartbeat during the job	starved (env-clear approach)	intact
Concurrent cron jobs	identity destroyed (env-clear approach)	identity survives
os.environ mutated	yes (env-clear approach)	not at all
Board pin (#20074)	destroyed (#78961)	untouched

• 18 new tests, covering the predicate, all five gates, run_job wiring, reset-on-exception, thread isolation, two concurrent cron jobs, and an AST invariant over _default_spawn that fails if the dispatcher gains a var that is neither identity-gated nor explicitly classified behaviour-only.
• Mutation-checked — 6 mutations, all caught: skip the context enter (1 fail), skip the reset (2), neuter the predicate (10), ungate _default_task_id (1), re-cache the kanban verdict (1), and reintroduce the os.environ clear (3, incl. the concurrency test). Snapshot-restored with no file drift.
• tests/cron/ + test_kanban_tools + test_kanban_stop 440 passed; test_model_tools + test_skill_utils + kanban boards 63 passed; ruff clean on all 6 files.
• E2E with real imports: leak reproduced then closed; heartbeat inputs intact during the job; concurrent jobs isolated with identity preserved.

Closes #78961