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.

src/ci_orchestrator/operations/executions.py

@@ -350,18 +350,27 @@ def _cached_runs(
     return runs, source, error, auth_failed, refused
 
 
-def _recency_key(run: Execution) -> tuple[int, int]:
+def _recency_key(run: Execution) -> tuple[int, int, int]:
     """Sort key for "newest first" (used with ``sorted(..., reverse=True)``).
 
-    Ordered by run id, then attempt -- not by ``started`` timestamp. Gitea
-    hands ``run_id`` out in creation order and it never changes across
-    re-runs, unlike ``started``: manually re-running an old workflow bumps
-    its ``started_at`` to now, which would sort that stale run above a
-    genuinely newer one under a time-based key. This also handles a queued
-    run (no ``started`` yet) for free -- it already has the highest id of
-    anything currently listed, no ``datetime.max`` special case needed.
+    Ordered by ``number`` -- the ``#N`` the Run column actually shows -- then
+    ``attempt``, then ``run_id`` only to keep ties stable. ``run_id`` is
+    Gitea's *instance-wide* id (shared across every repo/workflow the admin
+    endpoint pulls from), not a per-workflow counter, so it does not track
+    ``number`` at all once more than one workflow is in the mix: a run #53
+    from a rarely-triggered workflow can easily land a run id between two
+    #141/#142 runs from a busier one, putting #53's row between them even
+    though the column reads 142, 141, ..., 53. ``number`` is what "newest
+    first" has to mean here.
+
+    Two things this key deliberately does NOT sort by, both tried before:
+    ``started`` timestamp lets a manually re-run old workflow's ``started_at``
+    (bumped to now) jump it above a genuinely newer run even though its
+    number/id never changed; ``run_id`` alone is the instance-wide id
+    described above. ``attempt`` still breaks a same-number re-run correctly
+    (attempt 2 outranks attempt 1) without either flaw.
     """
-    return (run.run_id, run.attempt)
+    return (run.number, run.attempt, run.run_id)
 
 
 def _attach_vms(