Syncing releases from GitHub

First real feature of the sprint: release tracking, fed automatically from GitHub.

A release string is the single most useful tag on an error. "We're seeing a spike" is noise. "We're seeing a spike that started with 2.4.0" is a lead. Errors already carry a release field from ingest — but I want a first-class list of releases, with first-seen / last-seen, open-issue counts, and the ability to spot a regression right after a deploy.

Two sources, one list

Releases come from two places:

1. Ingest. Whenever an event arrives with a release value we haven't seen, we record it. Zero config — if your SDK sends a version, you get release tracking for free.
2. GitHub. A scheduled SyncProjectReleasesFromGitHub job pulls tags/releases from the connected repo and merges them in. Now a release shows up in Lookout before the first error from it, with its real publish date and commit.

The merge is the interesting bit: a release can be ingest-sourced, github-sourced, or both. If GitHub says 2.4.0 shipped at 09:00 and the first error arrives at 09:12, those are the same release and the UI shows one row, not two.

Why it earns its keep

Once releases are first-class, everything else can hang off them. "Errors by release." "Did p95 latency regress after the last deploy?" "Which release introduced this issue, and which one fixed it?" Today is just the list — but it's the spine that release-regression detection and incident correlation will attach to later in the sprint.

Next: teaching the SDK to trace Blade view rendering.