Measure lead time per commit, as DORA defines it

[trick77]

Lead time was measured as "the newest commit in each release" — it answers how stale the freshest change was, not DORA's "how long from commit to running in production". On the production export the difference is sevenfold, and the proxy is the flattering one:

	proxy (newest commit)	per commit (DORA)
prod p50	26.7 h	193.6 h (8 days)
prod p90	90.8 h	505.6 h (21 days)
intg p50	1.2 h	4.0 h

The gap between intg and prod is the actual finding: delivery is fast, the wait sits entirely in front of production.

How

Three views, layered so the fragile part is swappable:

• commit_sightings — expands the commits[] array that push payloads already carry (id, authorTimestamp, parents, author + type) into one row per commit on master. Measured: the array is capped at 5 per push, which bites 0.6 % of master pushes.
• deploy_commit_ranges — which commit range a deploy shipped, read today from the release-note bump links. This is the only view image_ref replaces, with "between the previous and the current successful deploy of this app" — no release notes, both release paths.
• lead_time_changes — each commit against the first deploy per environment that carried it, so a release rolling out to four Apps counts each change once.

The SQL lives in riptide_collector/views.py, imported by the migration and by the tests, so the definition that ships is the definition under test.

What counts as a change

Merge commits and service-account commits are classified, not dropped; the documented default excludes both — they are artifacts of shipping rather than changes that shipped. Bots get their own line instead of being blended: Renovate authored 87 % of commits reaching production here, so a blended median (209.3 h) describes the bot's cadence, not the team's.

Verification

• 242 tests pass, ruff + basedpyright clean. Seven new tests seed a synthetic release through testcontainers and assert the range boundaries, the once-per-change rule across two prod Apps, per-environment separation, and the classification columns.
• Migration applies, rolls back and re-applies against Postgres 17.
• Against the loaded export the views reproduce the prototype exactly: prod 984 changes / p50 193.6 h / p90 505.6 h, intg 1 375 / 4.0 h.

Docs: docs/dora-lead-time.md (definition, filters, limits), README lead-time row rewritten, one AGENTS.md line so the proxy does not come back.