Delete an email-report schedule (Snowflake native app only).

Permanently deletes the schedule and its recipients (cascade). Requires dashboard:write. The append-only dashboard.email audit rows for any past "Run now" send are in audit_logs and are NOT affected — deleting a schedule never erases the record that a report was emailed.

THIS ROUTE ANSWERS 404 feature-disabled ONLY WHEN THE SURFACE IS OFF, like every other verb under /v1/dashboards/{id}/email-schedules: all seven share the editionCapabilities.unattendedSchedules cell, and DVT-4490 ships it TRUE wherever emailSchedule is true — the normal Snowflake native-app case, answering normally here, not 404. 404 survives only with DVT_UNATTENDED_SCHEDULES_ENABLED=false on both dvt-api and dvt-engine, or on an edition where emailSchedule itself is false. When it does fire it precedes the path parse, so it is identical for a real schedule id and an invented one. Stored rows are unaffected either way. POST /v1/dashboards/{id}/email ("Email me this report now") remains the on-demand alternative regardless. Everything below describes the behavior every non-disabled install returns.

A plain row delete (DVT-4794, ADR-0069 Amendment 5 slice S3, D2): dvt no longer runs any Snowflake statement to stop a task before removing its own row, because dvt no longer creates that task in the first place — a dispatcher-driven (or never-activated) row has no task to stop. Deactivate is what clears the dispatcher pin, and is not required before DELETE for one of these rows. No caller token is required.

A LEGACY per-report task (taskDriver task) is the ONE exception (DVT-4794 r1 F4): its task is still the consumer's own, exactly as GET .../setup has always said — dvt does not own it and cannot remove it for them — so deleting the row would orphan a live Snowflake task with nothing left in dvt naming it. Refuses 409 schedule-deactivate-first instead: POST .../deactivate first (it clears the driver and returns retiredTaskName, the name to DROP TASK), then delete.