Scheduler creates duplicate execution records (skipped + success) for single trigger #91

Bug Description

A single schedule trigger produces two execution records — one with status success and one with status skipped. This is visible in the agent's execution history and is confusing since there is only one schedule configured.

Root Cause

The scheduler has two independent duplicate-prevention mechanisms that both fire for the same condition:

1. Distributed Redis lock (src/scheduler/service.py:524-527) — prevents cross-instance duplicates by returning silently if the lock is already held
2. APScheduler max_instances=1 event (src/scheduler/service.py:118-123) — fires EVENT_JOB_MAX_INSTANCES when a job is still running at the next internal check

The APScheduler event handler (_on_job_max_instances at line 407) calls _record_skipped_agent_schedule() which creates a "skipped" execution record — even though the distributed lock already handled concurrency and the "running" execution is the same trigger, not a genuinely separate one.

Timeline

T0  Cron fires → _execute_schedule() starts
T1  Lock acquired → create_execution(status="running")
T2  Agent work begins (takes minutes)
T3  APScheduler internal check sees job still running
T4  EVENT_JOB_MAX_INSTANCES fires → create_skipped_execution()  ← spurious record
T5  Agent work completes → update status to "success"

Key Files

Proposed Fix

Either:

1. Remove the EVENT_JOB_MAX_INSTANCES listener entirely — the distributed lock already handles concurrency, making the APScheduler event redundant
2. Add dedup logic in _on_job_max_instances() — check if there is already a "running" execution for this schedule from the current trigger window before creating a "skipped" record
3. Suppress the event by setting max_instances higher and relying solely on the distributed lock for concurrency control

Option 1 is the simplest and eliminates the race condition entirely. The "skipped" record was presumably added for observability, but it creates more confusion than value when it fires spuriously.

Impact

• User confusion: Execution history shows duplicate entries for a single trigger
• Incorrect metrics: Skipped count is inflated
• No data loss or functional impact: The actual task executes correctly once