Reconcile a discovery scan into monitors

Takes everything one scan of a repo or a host found and reconciles it against what this project already monitors: new sources become monitors, already-monitored sources are reported untouched, and monitors whose source has vanished are reported and never deleted.

This is what makes discovery re-runnable. A scan you can only run once is a setup wizard. A scan that is safe to re-run — nightly, on every CI build, on every deploy — is drift detection: "you added a scheduled workflow last week and nothing is watching it." Point it at the same repo every night and the answer converges.

The project comes from the API key, like every other endpoint here. There is no project id in the path.

The three rules

• A source that is new becomes a monitor and is returned under created.
• A source that is already monitored is returned under existing and is not modified — not its name, not its schedule, not its thresholds. Whatever a user tuned by hand survives every future scan.
• A monitor whose source is absent from the payload is returned under orphaned and is never deleted. Reporting it is the whole point; deleting it would mean a scanner bug or a wrong branch could tear down production monitoring.

Monitors created by hand carry no source identity. They are invisible to reconcile in both directions: a scan can neither adopt one nor report one as orphaned.

What a created monitor looks like

• schedule_cron present → a cron monitor on that expression, in the source's tz (default UTC), so LastPing arms a deadline from the same expression the job runs on. tz is required for crontab and systemd-timer sources that carry a schedule_cron: they fire in host-local time, and a UTC-assumed deadline on a host that is not on UTC is a false incident every day. Sending "UTC" explicitly satisfies it; omitting it is a 400.
• schedule_cron absent → an on_demand monitor. A push-triggered workflow has no cadence to be late against.
• expect_every_s (the silence floor) is seeded from the longest gap between consecutive fire times of schedule_cron, times two. The longest gap, because cron intervals are routinely irregular — 0 9 * * 1-5 alternates 24-hour gaps with a 72-hour one, and a floor set from the short gap would page every weekend. An explicit suggested_expect_every_s overrides it.
• grace_s is 300. A scanner has no way to know how late a job is allowed to be; that is a judgement about the business, not about the repository. PATCH it once and reconcile will never touch it again.
• No slug, and monitor_from is unset — so a freshly created monitor is not armed until its first ping, rather than paging minutes after every scan for jobs nobody has wired a ping into yet.

All or nothing

The write half runs in one transaction. Either every new monitor exists or none does — a half-created fleet would leave the caller unable to tell which half landed.