feat: scheduled maintenance windows

[amondnet]

Context / Motivation

Scheduled maintenance windows are a roadmap item in both the README and .please/docs/knowledge/product.md, and they are the single most-requested missing piece in comparable tools:

• Gatus ships maintenance windows.
• upptime has long-standing demand: Example: Scheduled maintenance tomorrow upptime/upptime#267 (7 reactions), Maintenance window start time is ignored upptime/upptime#872, maintenance issue: start and end keys for expectedDown services has been ignored and maintenance issues is being closed when an expectedDown service is down and up again outside start and end time upptime/upptime#349.

Without them, planned work pages the on-call and spams subscribers, and the status page shows a red bar for work that was announced in advance.

Proposed scope

• Declare maintenance windows either in config or in D1 (start, end, affected checks, description).
• Suppress alerting/notifications for affected checks while a window is active.
• Render upcoming and active maintenance as a banner on the status page, and include windows in the feeds.
• Drive window start/end transitions from a Worker Cron trigger — the same scheduled-publishing pattern emdash-cms/emdash uses for timed content.

Acceptance criteria

• A declared window suppresses notifications for its affected checks for its duration.
• The window renders as an upcoming banner before it starts and an active banner during it.
• The window appears in the RSS/Atom feeds.
• Start and end transitions fire from cron without a deploy or manual step.

Priority / Effort / Dependencies

• Priority: p2
• Effort: M (1–3 days)
• Dependencies: none hard. Related to incident persistence — maintenance renders alongside incidents and suppresses the notify pipeline.

[amondnet]

Related: #72 (dynamic config overlay). Maintenance windows should ride the same D1-overlay storage and D1 overlay > YAML precedence rather than introducing a second runtime-state mechanism.