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.

tests/python/test_operations_executions.py

@@ -454,21 +454,47 @@ def test_a_rerun_does_not_jump_above_a_newer_run(
     assert [(r.number, r.attempt) for r in view.runs] == [(13, 1), (12, 2), (12, 1)]
 
 
-def test_same_timestamp_falls_back_to_run_id(
+def test_a_lower_numbered_run_from_a_busier_workflow_does_not_land_in_between(
     tmp_path: Path, monkeypatch: pytest.MonkeyPatch
 ) -> None:
-    """Matrix runs share a timestamp; ids keep the order stable, not arbitrary."""
-    stamp = "2026-07-25T11:00:00Z"
+    """``run_id`` is instance-wide (every repo/workflow the admin endpoint
+    pulls from shares one sequence), not a per-workflow counter -- a rarely
+    triggered workflow's #53 can easily get a run id that falls between two
+    ids from a busier workflow's #141/#142, even though 53 is nowhere near
+    141 or 142. The Run column has to read by the number it shows, not by
+    that shared id."""
     payload = [
-        _run(run_id=10, number=10, started=stamp),
-        _run(run_id=12, number=12, started=stamp),
-        _run(run_id=11, number=11, started=stamp),
+        _run(run_id=9001, number=142, started="2026-07-25T12:00:00Z"),
+        # A different, rarely-run workflow's id landed between the two above
+        # purely because of when it happened to fire -- not because #53 is
+        # newer than #141.
+        _run(run_id=9000, number=53, path=".gitea/workflows/rare.yml", started="2026-07-25T09:00:00Z"),
+        _run(run_id=8000, number=141, started="2026-07-25T11:00:00Z"),
     ]
     _install_urlopen(monkeypatch, _admin_ok(payload))
 
     view = list_executions(_make_config(tmp_path), [], token="tok", now=_NOW)
 
-    assert [r.number for r in view.runs] == [12, 11, 10]
+    assert [r.number for r in view.runs] == [142, 141, 53]
+
+
+def test_same_number_and_attempt_falls_back_to_run_id(
+    tmp_path: Path, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """Two different workflows can land on the same run number independently
+    -- a real tie, not a bug. ``run_id`` just keeps the order stable/repeatable
+    rather than left to chance."""
+    stamp = "2026-07-25T11:00:00Z"
+    payload = [
+        _run(run_id=10, number=12, started=stamp),
+        _run(run_id=12, number=12, path=".gitea/workflows/other.yml", started=stamp),
+        _run(run_id=11, number=12, path=".gitea/workflows/third.yml", started=stamp),
+    ]
+    _install_urlopen(monkeypatch, _admin_ok(payload))
+
+    view = list_executions(_make_config(tmp_path), [], token="tok", now=_NOW)
+
+    assert [r.run_id for r in view.runs] == [12, 11, 10]
 
 
 # ── endpoint fallback ───────────────────────────────────────────────────────