[Nain9Dev]

Summary

ci_report.py measured only the wait of a run's first job. A job that needs another one is created
when its dependency ends, so the queue that builds up later in a run was invisible.

• Github.job_timings reads the jobs of a run from the REST API, which carries created_at (when the
  job became ready) next to started_at; gh run view does not.
• For the sampled runs, a new section "Queue time per job" gives the median, p90 and maximum wait, the
  job that waits longest and the runners online, so a high figure can be read against capacity.
• Skipped jobs and jobs that never started are not counted; a negative wait from clock skew is zero.
• The table row of the report is unchanged.

Verification

• tests/test_ci_report.py: 9 new tests (waits, percentile, section, real command, unreadable run);
  146 tests pass together; ruff format --check clean.
• Run against a real repository of the organisation over three days: 218 jobs sampled, median wait
  12 s, p90 10 min, 28 % of the jobs waited more than five minutes, mostly at the busy hours.

Notes

• One extra API call per sampled run (30 by default).