review classifier: the most classifications a run carries is a setting

The limit was a constant of ten in swarm-wire, so a repo with eleven rules
could not be reviewed and nothing short of a rebuild changed it. It is now
`max_classifications` in the classifier settings, beside
`max_concurrent_reviews`: 1 to 1000, ten until set, and a document stored
before the field decodes with the default. The classifier settings form in
the swarm UI gets a "rules per review" field, and the try-out's add button
stops at the saved limit instead of a hard-coded ten.

The controller checks a try-out, and a requested review's rules file, against
the setting where the run starts. The rules file itself may hold up to the
1000 the setting allows, so raising the limit needs no change to a repo.
A review whose rules exceed the limit posts a no-verdict comment saying so.

A run's reply deadline was a constant that covered ten classifications, a
minute plus three each. It is now computed from the run's own size, so a
bigger run waits as long as it needs and a default-sized one still waits 31
minutes. The classifier's answer window in the queue permissions covers the
biggest run the setting allows.

docs/4-implementation/scheduler/observability.md

@@ -603,7 +603,8 @@ adds to `verdicts` but runs no checks, so it adds nothing to `checks` or
 as `queue_failed` and a `no_verdict`. `no_answer` is a classification that
 failed, so a `no_verdict` run with a `no_answer` check is the usual cause of
 a comment instead of a review. The `check` values are the names in a repo's
-rules file, at most 10 per repo.
+rules file, at most the settings' `max_classifications` per repo (ten until
+set).
 
 The `review-classifier` dashboard in Grafana charts these.