fix(web): sort Executions by run number, not the instance-wide run id

The previous fix (sort by run_id/attempt) traded one bug for another:
run_id is Gitea's instance-wide id, shared across every repo/workflow the
admin endpoint pulls from, not a per-workflow counter. A rarely-triggered
workflow's #53 could land a run_id between two ids from a busier workflow's
#141/#142, putting #53's row between them in the Run column even though 53
isn't close to either -- exactly the reported symptom, now reproduced as a
regression test before the fix and passing after it.

run.number is the value the Run column actually displays; sort by that,
then attempt, then run_id only to keep a genuine same-number tie (two
different workflows landing on the same number independently) stable.

docs/WEB-UI.md

@@ -368,12 +368,18 @@ 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 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.
+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.
 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