#784 watch_gmail poll: stop+recreate leaves watch inactive (durable_cron idempotent on shared job_name)

All poll watches share job_name 'agent_sched_'+def_id[:8] where def_id is the FIXED SCHEDULED_AGENT_DSL definition -> every poll watch collides on one job_name (agent_sched_d0a0cb4c). stop_gmail_watch only DEACTIVATES (POST /workflows/schedules/{name}/cancel sets is_active=f; the API DELETE is also a soft cancel - row persists). On recreate, watch_gmail calls tools.cron.durable_cron with the same job_name; durable_cron is idempotent-by-job_name so it SKIPS, leaving the schedule inactive with the OLD goal -> recreate silently no-ops (goal change never takes; watch appears 'active' in the tool return but workflow_schedules row stays is_active=f). Observed while deploying #783: had to hard-DELETE the public.workflow_schedules row (DELETE FROM ... WHERE workflow_name='agent_sched_d0a0cb4c') before recreate produced a fresh active schedule with the new goal. FIX OPTIONS: (a) stop_gmail_watch hard-deletes the schedule (real DELETE, not soft cancel) so recreate is clean; (b) durable_cron upserts target_params/goal when job exists; (c) make job_name encode the goal/config hash so different goals don't collide. Also: /api/v1/schedules/{id} DELETE is a soft-cancel that leaves the row - misleading ('status: deleted' but row remains). Secondary: subject:highway match also catches GitHub CI notification emails (repo path contains 'highway') - consider tightening match guidance.