Fix GitHub Actions usage overcount for queued jobs

[snazy]

GitHub Actions job records can contain non-null started_at and completed_at timestamps even when the job never received a runner. In that state GitHub reports runner_name as empty and steps as empty, but the dashboard previously calculated usage as completed_at - started_at for every completed job timestamp pair. Jobs cancelled after waiting for unavailable capacity or impossible runner labels could therefore add days of wall-clock queue time to runner-minute usage.

Count runner usage only for jobs with a non-empty runner_name, while still counting cancelled jobs that were actually assigned to a runner. Store runner_name in serialized job records so future API responses can make the same distinction.

Normalize cached DB rows before returning API data. For new records this uses runner_name; for legacy serialized records that do not have runner_name, it falls back to empty steps as the no-runner signal. This lets detailed cached rows stop preserving inflated seconds_used values.

Add regression coverage for real runner jobs, queued/cancelled no-runner jobs, cancelled jobs after runner assignment, and legacy cached row normalization.

Generated-By: Codex-5.5 w/ my review

[snazy]

The core changes should all be covered by the new tests.

Only thing I could not verify is the behavior using a "real" ghactions.db, so starting the service locally with a copy of ghactions.db and compare the Mina / Java CI usage. The previously counted queued/cancelled but never ran jobs should no longer be visible in the report.