fix(web): sort Executions by run id/attempt, not started timestamp

Sorting by started_at let a manually re-run old workflow jump above a
genuinely newer run: the re-run's started_at bumps to now, but its run
number never changes, so the Run column stopped reading strictly
descending. run_id is assigned once at creation and never changes across
attempts, so (run_id, attempt) descending is both correct and simpler --
it also handles a queued run (no started_at yet) for free, no datetime.max
special case needed.

docs/WEB-UI.md

@@ -368,8 +368,13 @@ run. Every pill in the column — outcome pills and the VM-only `orphan`/
 sized to fit `cancelled`, the longest word) with left-aligned content, so the
 column reads as a clean list instead of ragged pill widths.
 
-Rows are ordered **newest first** (a queued run, which has no start time yet,
-sorts above everything; ties break on Gitea's run id). The row-count dropdown at
+Rows are ordered **newest first by run id, then attempt** — not by
+`started` timestamp. A queued run (no `started` yet) sorts above everything
+for free, since it already holds the highest id of anything currently
+listed. Sorting by time instead would let a manually re-run old workflow (its
+`started_at` bumped to now, its id unchanged) jump above a genuinely newer
+run; sorting by id/attempt keeps the Run column reading strictly descending.
+The row-count dropdown at
 the right end of the card's header bar picks how many to list — 10 / 25 / 50 /
 100, default from `[web].executions_limit` (10). The choice rides on the card's own polling URL
 (`/executions?limit=N`), so it survives every 5s refresh with no client-side