Add 'Off' collection preset + teach apply_collection_preset to mutate enabled

[erikdarlingdata]

Background

`config.apply_collection_preset` (install/41_schedule_management.sql:156) takes a named preset — `Aggressive`, `Balanced`, or `Low-Impact` — and bulk-updates `config.collection_schedule.frequency_minutes` for every collector in the preset table. Users already understand this abstraction.

It doesn't currently touch `enabled`. There's also no way to say "stop collecting for a while."

Recent tickets surface two gaps:

• [BUG] High Memory using Full Dashboard #835 / [BUG] Scheduled Master Collector is blowing up tempdb #885 asked for time-of-day scoping (quiet hours, overnight maintenance windows). A general-purpose blackout/quiet-hours system drags in timezones, DST, midnight wrap-around, per-collector windows, and catch-up logic when the window reopens.
• pgfiore in [BUG] Scheduled Master Collector is blowing up tempdb #885 specifically wanted "shut it all down overnight." Current answer is a `sp_update_schedule` window on the parent Agent job — blunt, works, but feels separate from the rest of the collection configuration.

Proposed

Two small changes to `apply_collection_preset`:

1. Add a fourth preset: `Off` (or `Idle` / `None`). Sets `enabled = 0` across every row in `config.collection_schedule`. No frequency changes.
2. Teach the existing three presets to set `enabled = 1` when they run. This guarantees that switching back from `Off` reliably reactivates collection — otherwise `Off → Balanced` would update frequencies but leave every collector disabled.

With those two changes, time-of-day scoping becomes a pure SQL Agent composition:

```sql
-- Agent job "Overnight quiet hours - start" (schedule: daily 22:00)
EXECUTE config.apply_collection_preset @preset_name = N'Off';

-- Agent job "Overnight quiet hours - end" (schedule: daily 06:00)
EXECUTE config.apply_collection_preset @preset_name = N'Balanced';
```

Zero new schema. Zero new collector code. Agent owns time zones and DST. The switchover is idempotent (`UPDATE` statements). No "should I skip this run?" decision per collector, so no catch-up burst problem.

Scope

• Add `Off` to the valid preset list in `config.apply_collection_preset`.
• Update the three existing preset branches to also set `cs.enabled = 1` in the final `UPDATE`.
• Add the `Off` branch: `UPDATE config.collection_schedule SET enabled = 0, modified_date = SYSDATETIME();` (no `next_run_time` reset needed).
• Update the proc's header comment and the `PRINT` block at the bottom of the file to list `Off`.
• Document the two-Agent-jobs pattern in README / install notes with a ready-to-paste `sp_add_job` example.

Main tradeoff

Teaching non-`Off` presets to set `enabled = 1` means applying any preset will re-enable collectors the user had manually disabled. That's usually the desired behavior (one switch, consistent state) but it quietly overrides a manual `UPDATE config.collection_schedule SET enabled = 0`. Two options:

• Accept it and call it out clearly in the preset's description / docs.
• Add a `@preserve_disabled bit = 0` parameter for users who want to keep their per-collector overrides.

I'd start with the simpler behavior and add the parameter only if someone asks.

Out of scope

• Per-collector time windows (different collectors on different schedules). Still composable via Agent job schedules that target a specific `apply_collection_preset` call, but no built-in config surface.
• Declarative preset schedule table (`config.preset_schedule`). Could follow if the Agent-job pattern proves inadequate.

Related

• [BUG] High Memory using Full Dashboard #835, [BUG] Scheduled Master Collector is blowing up tempdb #885 — original time-of-day / quiet-hours asks.
• Database exclusion is orthogonal; tracked separately.

[erikdarlingdata]

Shipped in PR #891 (merged to dev). The Off preset is now available, and config.apply_collection_preset will mutate enabled accordingly when switching to/from Off.