v1.0.405

Show alerts as an expandable list

Each alert is one row: a status dot, its name, a one-line summary of what
tripped (or "All clear, N checks"), when it last checked, and its Checks and
Emails switches. A row expands into its checks, advice, Check now and the
alert's dashboard, which only loads while the row is open.

Problems sort to the top and open on their own. A row's open or closed state
is remembered per status, so a new trip reopens a row that was collapsed
while clear. Pausing never reorders the list, so a switch never moves out
from under the pointer.

Add an Alerts system with per-alert dashboards and switches

Any source, usually a custom job, can POST its checks to /api/alerts/report.
DocVault keeps each check's trip history in .docvault-alerts.json and emails
the first configured recipient only when a check trips, then every 6 hours
while it stays tripped. Recoveries never email. Three failed reports in a
row, or no report for three of the job's intervals, sends one "blind" email
per outage.

An alert can bring its own page: DATA_DIR/alerts//dashboard.html is
served under a sandbox CSP (scripts, no network, no same-origin access) and
shown in a script-only iframe that receives the source's data by
postMessage. Sources without one get generic history charts.
web/examples/alerts documents the report contract and message protocol and
ships a starter dashboard.

Each source card has a Checks switch (the job's enabled flag, through the
existing jobs endpoint), an Emails switch that keeps checks running but
sends nothing, Check now, stale and failed states, and the alert log.

Allow minute-level custom job schedules

Custom jobs can now run "every Nm" with N of at least 10, for monitors that
need to react faster than hourly. Shorter schedules are rejected because the
runner never re-runs a job within 10 minutes of its last attempt. The new-job
form offers every 15m and every 30m.