docs: the review classifier's try-out service, its key and its subject

- review-classifier.md: claude runs spawn through hive-claude directly
  with no tools and no session (hive-runtime holds only TurnStop); the
  answer's fields, the 500-character reason cap and what a failure does;
  how the try-out page reaches the classifier; the settled parts of the
  open list (API key path, try-out subject, --tools "" on claude).
  The banner stays.
- services.md: a Review classifier section with the two operator steps.
- secrets.md, credentials.md: the classifier's leaf and the key row.
- network.md: the container's row. CLAUDE.md: the crate.

docs/swarm/review-classifier.md

@@ -98,14 +98,16 @@ It looks like an agent from the inside, with three things missing: it has no
 full agent identity, no state directory and no tools. Every model session is
 ephemeral, and nothing carries over from one run to the next.
 
-The model sessions run through [`hive-runtime`](../../hive-runtime/README.md),
-the crate `hive-agent` and `hive-subagent-mcp` already drive their turns
-through: the `Runtime` trait in `hive-runtime/src/lib.rs`, with
-`ClaudeRuntime` and `AcpRuntime` behind it. That trait runs turns on a durable
-session, and the subagent daemon's claude path
-(`hive-subagent-mcp/src/session.rs`) spawns claude directly. A refactor
-first moves the cancellable per-turn claude session into `hive-runtime` and
-moves the subagent daemon onto it; the classifier builds on that shared seam.
+On the claude runtimes, each classification is one `claude --print` the
+service spawns through the `hive-claude` crate directly, with no session to
+resume, no tools (`--tools ""`), no MCP server (`--strict-mcp-config` and no
+config) and an empty directory of its own. A classification needs no durable
+session, so the service doesn't use [`hive-runtime`](../../hive-runtime/README.md),
+whose `Runtime` trait drives the agents' durable sessions.
+
+The service is `swarm-review-classifier`, and its container is the one
+[`services.md`](services.md#review-classifier) describes. It holds no forge
+credential: `swarm-controller` reads the PR and sends it along.
 
 ### Swarm-level settings
 
@@ -147,9 +149,9 @@ The model answers each classification in JSON. The answer holds:
 
 - a **verdict**, one of _match_, _no match_ or _not applicable to this PR_
 - a **certainty** from 0 to 100, how sure the model is of that verdict
-- a **reason**, limited in length
+- a **reason**, at most 500 characters
 
-An illustrative answer, with placeholder field names:
+An answer:
 
 ```json
 {
@@ -159,6 +161,13 @@ An illustrative answer, with placeholder field names:
 }
 ```
 
+The verdict field holds `match`, `no-match` or `not-applicable`, and the
+certainty field a whole number. A runtime error, a timeout, or an answer that
+isn't that JSON object leaves the classification without a verdict: it's listed
+with its error, and doesn't count. A run with no API key, or in which no
+classification got an answer, fails as a whole, and shows its error instead of a
+verdict.
+
 ### Aggregation into the verdict
 
 The classifier collects the answers into one result, keyed by
@@ -224,6 +233,14 @@ repo and a PR, write or edit a classification, and run it against that PR;
 change the prompt and run it again until it answers the way you want.
 Nothing reaches the forge while you iterate.
 
+The page posts the run to `swarm-controller` (`POST
+/api/review-classifier/try-out`), which reads the PR with its own forge token
+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.
+
 When it's ready, **open a PR** has the service account push a branch that
 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
@@ -234,7 +251,8 @@ that branch, where you log in as usual and open the PR yourself.
 The swarm UI shows no token counts, cache counts or cost, on any page. On the
 claude runtimes, every classifier run starts its `claude` process with
 `OTEL_RESOURCE_ATTRIBUTES` naming the repo and the PR, so the cost reads from
-the metrics store by repo and PR. On a subscription, cost is notional.
+the metrics store by repo and PR. The process exports to the hive-tier collector on
+the classifier's host, where that host runs one. On a subscription, cost is notional.
 
 On the ACP runtime, the harness counts the agent's `usage_update` running
 totals and exports them as `hyperhive.agent.cost.usage`, labelled with only
@@ -255,13 +273,8 @@ These get settled, and filled in here, as the work reaches them:
   token counts before choosing.
 - **Run store and retention.** Where run records live, how long they stay,
   and how the recent-runs page reads them.
-- **Failure handling.** What a runtime error, malformed JSON, a timeout or a
-  rate limit does to a classification and to the verdict.
-- **JSON validation and the reason cap.** The exact answer schema, and the
-  reason's length limit.
 - **Oversized diffs.** What happens when the diff doesn't fit the model's
-  context, and whether lockfiles collapse as in `hive-forge diff`
-  (`hive-forge/src/verbs/diff.rs`).
+  context. Lockfiles already collapse to one line each, as in `hive-forge diff`.
 - **Stale reviews.** Whether the repo's stale-review dismissal setting
   retires the bot's review on an older commit, or the service dismisses its
   own earlier review when it posts a new one.
@@ -272,16 +285,19 @@ These get settled, and filled in here, as the work reaches them:
   whether anything gets redacted.
 - **Prompt injection.** A PR's diff and commit messages are model input, so
   a PR can try to talk the classifier into approving it.
-- **The "no tools" mechanism.** How each runtime runs a session with no
-  tools at all.
-- **Credential paths.** Where in bao the runtime credentials and the service
-  account's forge token live, and which component holds the token.
+- **The "no tools" mechanism on ACP.** How the ACP runtime runs a session with
+  no tools at all. The claude runtimes pass `--tools ""`.
+- **Credential paths.** Where in bao the ACP and subscription runtimes'
+  credentials and the service account's forge token live, and which component
+  holds the token. The API key is at
+  `secret/swarm/services/review-classifier/anthropic-api-key`, field `api_key`.
 - **Model naming across runtimes.** How the swarm-level model setting
   handles runtime-specific model names.
 - **ACP cost labels.** How an ACP run's cost gets a repo and PR label, so
   it reads from the metrics store like the claude runtimes' cost.
-- **Async message medium.** Which queue subjects or streams carry the
-  messages between `swarm-controller` and the classifier.
+- **Async message medium for review runs.** Which queue subjects or streams
+  carry a webhook-started run. A try-out is one request on
+  `$SWARM.review-classifier.try-out`, answered on its reply subject.
 - **Reviewer handoff.** How a later reviewer, human or agent, learns the
   classifier passed a PR before it starts its own review.
 - **Opt-in details.** Beyond the config file: the service account's access
@@ -289,5 +305,3 @@ These get settled, and filled in here, as the work reaches them:
   branches.
 - **Commit author for try-out PRs.** How the classifier derives the commit
   author's name and email from the swarm UI login.
-- **Refactor scope.** How much of `hive-agent`'s and `hive-subagent-mcp`'s
-  runtime code moves into `hive-runtime` before the classifier uses it.