fix(web): Executions sorts by actual global recency, not per-repo run number

number is a per-repo/workflow counter with no meaning once the admin
endpoint mixes every repo on the instance into one feed -- a rarely-run
workflow's low #53 that just fired outranked a busier workflow's #142 from
hours earlier, but sorting by number buried it instead. Sort by started
(globally comparable) with run_id/attempt as tiebreaks; a re-run bumping
started_at back to the top is correct, not a bug, under "most recent
globally".

docs/WEB-UI.md

@@ -386,18 +386,16 @@ 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 by run number, then attempt** — the `#N` the
-Run column actually shows, not `started` timestamp and not `run_id` either.
-Both were tried and both break once more than one repo/workflow is in the
-mix (the admin endpoint pulls from every repo on the instance): sorting by
-time lets a manually re-run old workflow (its `started_at` bumped to now,
-its number unchanged) jump above a genuinely newer run; sorting by `run_id`
-looks right for a single workflow but `run_id` is an *instance-wide*
-sequence shared by every repo/workflow, not a per-workflow counter, so a
-rarely-triggered workflow's #53 can land a `run_id` between two ids from a
-busier workflow's #141/#142 — putting #53's row between them even though 53
-is nowhere near 141. `run.number` is the only one of the three that means
-what the column header says.
+Rows are ordered **newest first by actual start time, globally** —
+`run.started` (a run still queued reads as "now", since it was only just
+created), with `run_id` then `attempt` as tiebreakers for runs sharing the
+exact same timestamp. `run.number` is deliberately *not* the sort key: it is
+a per-repo/workflow counter, and the admin endpoint mixes every repo/workflow
+on the instance into one feed, so a rarely-triggered workflow's #53 that just
+fired legitimately outranks a #142 from a busier workflow that ran hours
+earlier — sorting by `number` would bury it. A manual re-run bumping
+`started_at` and jumping its row back to the top is not a bug either: it
+really is the most recent activity on that run.
 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