Summary

Describe the problem and fix in 2-5 bullets:

• Problem: Manual cron job triggers from both the API/tooling and the dashboard Run button returned ok: true / enqueued: true, but isolated cron sessions were never spawned, so the job silently never executed.
• Why it matters: This breaks the operator escape hatch for cron jobs. Scheduled runs still work, but any manual retry, backfill, or on-demand execution path becomes a no-op even though the caller sees a success response.
• What changed:
  • Identified that manual cron.run dispatch was enqueuing onto the same global cron lane later re-entered by isolated cron agent turns, which created a self-deadlock.
  • Added a dedicated cron-dispatch lane for manual background dispatch while keeping actual cron job execution on the existing cron lane.
  • Wired the new lane into startup and reload concurrency configuration so it respects the same cron concurrency cap.
  • Added regression coverage in src/cron/service.issue-regressions.test.ts to prove manual isolated runs no longer deadlock when the isolated executor re-enters the cron lane.
• What did NOT change (scope boundary): Scheduled cron execution logic is unchanged. Cron job payload semantics, isolated session behavior, and the dashboard/API contract are unchanged aside from manual triggers now actually executing.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: Cron: manual job triggers via API/dashboard enqueue but never execute #41507

User-visible / Behavior Changes

Users manually running cron jobs from the dashboard or the cron.run API/tool path will now get a real isolated execution instead of a silent enqueue-without-execution no-op.

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js 22.x+
• Model/provider: N/A
• Integration/channel (if any): Gateway cron API + dashboard/manual trigger path
• Relevant config (redacted): Cron job with sessionTarget: "isolated" and payload.kind: "agentTurn"

Steps

1. Create or use an existing cron job that successfully runs on schedule.
2. Trigger it manually through the dashboard Run button or cron run --jobId <id> --runMode force.
3. Inspect cron run history and session spawning.

Expected

• Manual trigger enqueues background work, spawns the isolated cron session, and records run history.

Actual

• Prior to this PR, the API returned success but the work was deadlocked on the shared cron lane, so no isolated session spawned and no run history was recorded.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

(Note: Added a regression test that simulates the isolated executor re-entering the cron lane and confirms the manual run completes instead of stalling.)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios: Ran pnpm exec vitest run --config vitest.config.ts src/cron/service.issue-regressions.test.ts and pnpm exec vitest run --config vitest.config.ts src/gateway/server.cron.test.ts after the fix.
• Edge cases checked: Verified that the manual dispatch path uses a separate lane while isolated cron execution can still enqueue work onto the existing cron lane without deadlocking.
• What you did not verify: Did not manually click the dashboard Run button or exercise a live cron job on a running gateway instance.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: Revert this specific PR commit.
• Known bad symptoms reviewers should watch for: Cron manual triggers start but unexpectedly ignore the configured cron concurrency cap, which would suggest the new dispatch lane is no longer sharing the expected concurrency setting.

Risks and Mitigations

• Risk: Adding a second lane for manual dispatch could drift from the configured cron concurrency if its limit is not kept in sync.
  • Mitigation: The new cron-dispatch lane is explicitly initialized and reloaded with cfg.cron?.maxConcurrentRuns ?? 1, and regression coverage exercises the deadlock case directly.