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

Partial update (merge patch), requires dashboard:write (DVT-4266). Editable: title, cron or preset, timezone, pageId, subject, recipients and enabled. Changing the cadence or timezone recomputes nextRunAt atomically. recipients, when supplied, REPLACES the whole set.

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 timezone that cannot be resolved to an IANA zone is a 422 (DVT-4321), not a 400; the failing value is echoed in a timezone extension field. A blank timezone, or "Local", normalizes to UTC rather than being rejected. A cron/preset change is also 422 cadence-too-fine (DVT-4794, ADR-0069 Amendment 5 slice S3, D5) when the new cadence fires more often than every 15 minutes; a PATCH that does not touch cron/preset is never refused for cadence, even on a row whose stored cron predates this floor.

On an already-ACTIVATED schedule (activatedAt non-null), a recipients/pageId/ cron/timezone/enabled change is compared against the PINNED terms Activate recorded, not against the row's own live value (DVT-4794, ADR-0069 Amendment 5 slice S3, D3): adding a recipient not already pinned, changing the page scope (including to/from "every page"), changing the cadence, or turning enabled back on all WIDEN what the dispatcher will send. Removing a recipient, or any other field, never widens. A widening PATCH is applied only when the actor holds schedule:activate (D8) AND passes a live-admin recheck run inline on this same request; when it does, the widened pin field(s) move to the new value(s) in the SAME transaction. When it does not, the PATCH still applies but the row drops to fully unactivated in that same transaction, and the response's activationDropped names why.

A pageId change on an already-activated row is validated against the PINNED revision (activatedRevisionId), not the dashboard's live spec: a page added to the dashboard after this schedule was activated is 422 page-not-in-activated-revision, regardless of which branch above the PATCH would otherwise take — re-activate first to pin the revision that has it.