Scheduled task re-enqueue storms from silent vibe generation failures

A twice-daily cron job (maybe_enqueue_pulse_digest) checks whether vibes exist for each slot and re-enqueues if not, with a 20-minute cooldown. When generate_vibes silently failed (due to a dspy.settings thread-affinity error), no vibes were ever created, so the cron re-enqueued every 20 minutes — producing a storm of failed tasks that all hit the same error.

The cascade:

1. Worker thread A (community engagement) configures dspy.settings first
2. Worker thread B (pulse digest) tries dspy.settings.callbacks = ... → RuntimeError
3. generate_vibes fails, caught by broad except Exception in run_pulse_digest → logged but edition still 'succeeds' with 0 vibes
4. Cron tick checks vibe_exists → None → re-enqueues after cooldown
5. Loop repeats every 20 minutes indefinitely

Lessons:

• Idempotent schedulers that check 'is work done?' can amplify silent failures into infinite retry loops. The scheduler's definition of 'done' (vibes exist) must match the failure mode (vibes never created).
• Use dspy.context() (thread-local override) instead of dspy.settings.X = ... (global mutation with thread affinity) in any multi-threaded worker environment.
• Broad except Exception around vibe synthesis was correct (edition ships without vibes), but the scheduler didn't account for this partial-success state.