swarm-controller: record the review classifier's runs and list them

Every run is recorded when it ends: a try-out when its reply settles it,
a requested review once its review is posted or the post fails, and a
request turned away by a full queue once its comment is posted. A
duplicate request that starts nothing is not recorded. The newest 100
are one JSON array under `recent` in a new controller-owned KV bucket,
`review-classifier-runs`, written with compare-and-set as
`schedule-definitions` is (five attempts). A failed write is logged; the
review is already posted by then.

Each recorded run is also one info event, "review classifier run
finished", with the record's fields as tracing fields. The controller
logs natively to the journal, so they reach VictoriaLogs as F_<NAME>.

GET /api/review-classifier/runs returns the list, newest first, gated
by the gateway like the try-out GET. post_classifier_review now returns
the posted review's html_url, which the record keeps as review_url.

Closes #5153, part of #5096.

docs/swarm/review-classifier.md

@@ -294,8 +294,8 @@ The page posts the run to `swarm-controller` (`POST
 and sends it to the classifier as one queue request on
 `$SWARM.review-classifier.try-out`. The page then reads the result back (`GET
 /api/review-classifier/try-out/{id}`): a run can take longer than a request
-stays open. The controller keeps the result in memory for an hour; there is no
-run store.
+stays open. The controller keeps the result in memory for an hour, and the
+finished run goes into the [run store](#run-store-and-retention).
 
 `GET /api/review-classifier/rules?repo=owner/name` returns the repo's own
 rules, for the page to load into its editor; a run posts them like typed
@@ -332,6 +332,60 @@ adds the classification to the repo's config, with you, the swarm UI user,
 as commit author. The page then links you to the forge's new-PR page for
 that branch, where you log in as usual and open the PR yourself.
 
+## Run store and retention
+
+`swarm-controller` records every run when it ends: a try-out when the
+classifier's reply arrives, a requested review once the controller has posted
+its review or the post has failed, and a request turned away because the
+queue was full once its comment is on the forge or the post has failed. A review request for a head that's already
+running or waiting starts nothing and isn't recorded. A run still going isn't
+in the list, and a controller restart drops a run in progress.
+
+The newest 100 runs are one JSON array under the key `recent` in the
+`review-classifier-runs` KV bucket on the swarm queue, which only the
+controller reads or writes. The controller creates the bucket on first use and
+adds each run with a compare-and-set write, so the list survives a controller
+restart or a move to another host. Recording the 101st run drops the oldest;
+there's no time-based retention. The controller logs a failed write, and it
+changes nothing on the forge.
+
+`GET /api/review-classifier/runs` returns the list, newest first. Like the
+try-out GET, the gateway's `admins` rule gates it, and the controller checks no
+header. Each run has:
+
+- `id`: a try-out's is the id its POST answered with
+- `trigger`: `try-out` or `review`
+- `repo` (`owner/name`), `pr`, and `requester`: the swarm UI user who started
+  the try-out, or the forge user who requested the review
+- `head_sha`: the commit the run read, absent when the PR wasn't read, as for
+  an unreadable PR or a full queue
+- `started_unix` and `finished_unix`: a try-out starts at its POST, a review
+  once it has a run place
+- `outcome`: `approved`, `changes-requested`, `no-verdict`, `queue-full` or
+  `post-failed` for a review; `done` or `failed` for a try-out
+- `detail`: the reason, for every outcome but `approved`,
+  `changes-requested` and `done`. For `post-failed` it's the run's own reason,
+  when it has one, then why the post failed.
+- `rows` and `overall`, as the try-out GET returns them, when the classifier
+  answered
+- `review_url`: the posted review, when the forge names its URL
+
+A run holds no diff, no commit text and no token count or cost. The route
+answers 503 when the controller has no swarm queue or can't reach the bucket,
+and 500 when it can't read the list, both as problem+json.
+
+Each recorded run is also one `info` event from `swarm-controller` with the
+message `review classifier run finished`. The event carries the same fields,
+with `rows` as JSON. It reaches VictoriaLogs through the host journal, where
+each field arrives as `F_` and the name in capitals (`F_OUTCOME`, `F_REPO`), so
+a run whose write failed is still there:
+
+```console
+$ swarm-logs query '_time:7d _SYSTEMD_UNIT:="swarm-controller.service" _msg:="review classifier run finished" | fields _time, F_TRIGGER, F_REPO, F_PR, F_OUTCOME, F_DETAIL, F_REVIEW_URL' --format json
+```
+
+Add a filter such as `F_OUTCOME:="post-failed"` before the `|` to narrow it.
+
 ## Observability and cost
 
 The swarm UI shows no token counts, cache counts or cost, on any page. On the
@@ -357,8 +411,6 @@ These get settled, and filled in here, as the work reaches them:
 - **Cache strategy.** Fully independent sessions per classification, or one
   warm session and then the rest in parallel. To measure through the cache
   token counts before choosing.
-- **Run store and retention.** Where run records live, how long they stay,
-  and how the recent-runs page reads them.
 - **Oversized diffs.** What happens when the diff doesn't fit the model's
   context. Lockfiles already collapse to one line each, as in `hive-forge diff`.
 - **Budget.** Any per-run or per-day spend limit on top of the concurrency