Fix scheduled skill lifecycle duplication

[cursor]

Bug and impact

Scheduled jobs that resolved a skill were running skill lifecycle hooks twice after /runs gained lifecycle handling: once in SchedulerService._schedule_job() and again inside process_run(). A scheduled market_analyst job could get its prompt wrapped twice, web_clipper could fetch/archive twice, and failed scheduled runs could still emit scheduler success notifications.

Celery enqueue failures could also leave a durable run stuck in accepted/starting after the row was written but before a task was queued.

Root cause

The scheduler kept its pre-existing skill resolve/success/failure hook calls while delegating execution to process_run(), which now owns the same lifecycle. The Celery execution boundary propagated .delay() failures without updating run status.

Fix

• Make scheduled jobs pass the original query and optional skill_id to process_run() and stop invoking skill lifecycle hooks in the scheduler.
• Treat non-completed process_run() results as scheduler failures, so scheduler notifications match terminal run status.
• Mark run-store/audit status failed when Celery enqueue fails, preserving metadata about the enqueue error.
• Add focused regression tests for scheduler lifecycle delegation and Celery enqueue failure status handling.

Validation

• PYTHONPATH=/tmp/s18-test-deps python3 -m pytest tests/test_skills_runs.py tests/test_celery_app.py — 8 passed, 1 Starlette/httpx deprecation warning.