[#2079] Use first-parent chain for next checkout

## Parent

https://github.com/kernelci/dashboard/issues/2079
Schema: https://github.com/kernelci/dashboard/issues/2089
Fill: https://github.com/kernelci/dashboard/issues/2109
Related: https://github.com/kernelci/dashboard/issues/1958

Blocked on [#2109](https://github.com/kernelci/dashboard/issues/2109) (ancestor rows in `commits` / `commit_parents`). Not blocked on closed [#2091](https://github.com/kernelci/dashboard/issues/2091).

Issue extras “next checkout” currently picks the earliest later checkout on the same tree by `start_time` ([#2054](https://github.com/kernelci/dashboard/pull/2054)). That is CI clock order, not git history.

Once `commits` has parent **and ancestor** data, use the **first-parent** chain instead.

## In scope

- For last-seen checkout hash `H` on a tree/branch, look at **later checkouts on that same tree/branch** and pick the nearest whose first-parent ancestry reaches `H` (walk **backward** from those checkouts along `commit_parents` where `ord = 0`).
- Do **not** pick “the commit whose first parent is `H`”. Many commits can share that first parent (rebase, cherry-pick, other trees). Disambiguate with checkouts we already have; no `trees` / `named_refs` table in this issue.
- Use `commit_parents.ord = 0` from [#2089](https://github.com/kernelci/dashboard/issues/2089).
- Bound the walk; if `H` is missing from `commits`, the chain is gappy, or no later checkout reaches `H`, **keep the current `start_time` behaviour**.
- Same `NextCheckout` payload / API shape unless a field is clearly wrong.

## Tests

Linear history: next checkout is the nearest later checkout on the first-parent chain, not an older `start_time` neighbour. Merge: first parent, not second. Two first-parent children of `H`: pick via later checkouts on the same tree/branch, not an arbitrary child. Missing `commits` row: fallback to `start_time`.

Start at the issue-extras “next checkout” implementation and its current start_time selection, then inspect the commits and commit_parents data described in #2109 and #2089. Verify the listed linear, merge, multiple-child, missing-row, gappy-chain, and no-match cases; it is done when first-parent ancestry selects the nearest eligible checkout and all fallback cases retain start_time behavior.

Written by the indexing model from the issue text.