fleetd #201/#227 unit 5: wire errorPattern, cool-off spawn gate, and fleet views

Wires the already-merged units into production:
- Per-profile errorPattern config (beside exhaustedPattern), compiled once at
  startup; falls back to the legacy (?i)\bAPI Error\s*: pattern when unset.
  Startup logs configured-vs-legacy coverage, same as exhaustedPattern.
- One production BackendErrorSink in Fleetd.java: mark backend_error on the
  session, resolve the profile's credential fail-loud (never
  Optional.ifPresent), record it in BackendOutagePolicy, and push a lead
  nudge on a new incident.
- CompositePeerLauncher's explicit and automatic spawn paths both refuse a
  cooling-off credential; exhaustion quarantine wins when both are active.
  PlacementContext gets a separate coolingOff set so refusal text says
  "cooling off", never "exhausted".
- fleet_list/fleet_profiles report coolingOffForSeconds as an independent
  fact from quarantinedForSeconds; both can appear together.
- fleetd.example.yaml documents errorPattern and the 2/60/60 cool-off policy;
  CLAUDE.md tells leads how to read the two independent outage states.

Also: FixedPlacementPolicy.java, not in the original file list, needed the
same coolingOff filtering as PlacementPolicyUtil (it does its own inline
candidate filtering rather than delegating).

1190 tests, 0 failures (up from the 1163 baseline); BUILD SUCCESS.

fleetd/fleetd.example.yaml

@@ -206,6 +206,39 @@ herdrSocket: ~/.config/herdr/herdr.sock
 #                      profile quarantines alone, under its own name, exactly as if the field did
 #                      not exist. Cooldown length is the top-level quarantineCooldownSeconds below.
 #                      HOT: read live at every spawn/exhaustion check — no restart needed.
+#   errorPattern     → fleetd #201 / #227: regex matched against a completion-fallback scrape to
+#                      classify a turn that ended with no fleet_reply as a BACKEND ERROR — a
+#                      credential outage or a provider 5xx — rather than a real answer or a
+#                      usage-limit exhaustion (exhaustedPattern above always wins when a line
+#                      matches both). Opt-in. Omit it and this profile falls back to fleetd's
+#                      built-in legacy pattern `(?i)\bAPI Error\s*:` — classification still
+#                      happens, just without a profile-specific match; every backend words its
+#                      failure differently, so a hardcoded sentence would only ever match one
+#                      of them.
+#                      DEFERRED: compiled once into a startup pattern map, same as exhaustedPattern
+#                      — editing it needs a daemon restart.
+#                      # errorPattern: "503 Service Unavailable"   # opt-in: classify a backend outage
+#
+#                      What happens once a match fires (BackendOutagePolicy, credentialId-keyed,
+#                      SEPARATE from the CB-578 stage B quarantine above and never merged with it):
+#                        - threshold 2 — TWO DISTINCT TARGETS (never raw events) on the same
+#                          effective credential inside a 60-second window start an "incident" and a
+#                          60-second cool-off for that credential. One member repeating the same
+#                          classified line twice never cools anything off — a real outage hits
+#                          every target on that credential, so requiring a second, independent
+#                          target loses nothing against the case this guards against, while
+#                          protecting against a heuristic misfire on one flaky member.
+#                        - a fresh error while a credential is already cooling off is ignored
+#                          outright: it neither extends the 60s deadline nor starts a new incident.
+#                        - `fleet_list`/`fleet_profiles` report a cooling credential with
+#                          `coolingOffForSeconds` (never `quarantinedForSeconds`, unless CB-578
+#                          exhaustion quarantine is ALSO independently active for the same
+#                          credential — the two checks can both fire at once). A spawn onto a
+#                          cooling profile is refused with a message naming the credential and
+#                          remaining seconds — "cooling off", never "exhausted", so an operator can
+#                          tell a short transient fault from a spent subscription at a glance.
+#                        - the lead gets ONE nudge per incident (not one per affected target), via
+#                          the same push loop that already delivers ticket/question reminders.
 #   env              → extra environment for this profile's workers, as a literal key/value map
 #                      (CB-511). Use it to give workers a toolchain.
 #
@@ -273,6 +306,7 @@ profiles:
     # gitHostEnv: GITEA_HOST          # defaults to GITEA_HOST; injected only with gitTokenEnv
     # exhaustedPattern: "usage limit has been reached"   # opt-in: classify a usage-limit refusal (CB-578)
     # credentialId: shared-openai   # opt-in: quarantine together with every other profile sharing this id (CB-578)
+    # errorPattern: "503 Service Unavailable"   # opt-in: classify a backend outage (fleetd #201/#227) — see the key doc above
     # configDir: /Users/me/.ccs/instances/gx10   # CLAUDE_CONFIG_DIR — inherit that profile's skills/MCP
     # cwd: /Users/me/src/myrepo       # pin the working dir; omit to inherit the primary's
     # parityOverlay: [".env", ".envrc"]   # the default; never add .mcp.json or .claude/settings.local.json — see above
@@ -369,6 +403,12 @@ placement: weighted
 # DEFERRED: baked once into the BackendQuarantine built at startup — a running quarantine keeps
 # its original cooldown regardless; a new value only applies to a quarantine that starts after a
 # restart. Editing this needs a daemon restart to take effect.
+#
+# This does NOT govern the fleetd #201 / #227 backend-error cool-off documented under errorPattern
+# above — that mechanism is a separate, shorter-lived, NOT-configurable policy (threshold 2 distinct
+# targets, 60-second window, 60-second cool-off), on purpose: it exists to survive a brief transient
+# fault, not to replace this 30-minute exhaustion quarantine. Do not conflate the two when reading
+# fleet_list/fleet_profiles — coolingOffForSeconds and quarantinedForSeconds are independent facts.
 # quarantineCooldownSeconds: 1800
 
 # Re-read this file without restarting the daemon (CB-559). Off unless you add this block, so an
@@ -395,8 +435,10 @@ placement: weighted
 #               stage B — baked once into the quarantine tracker built at startup), ADDING or
 #               REMOVING a profile (a new backend needs its own launcher, and launchers are built
 #               once), AND an existing profile's launch settings — model, baseUrl, argv, env,
-#               configDir, mcpUrl, tabLabel, exhaustedPattern. The launcher takes a copy of
-#               `profiles:` at startup and resolves every spawn out of that copy, so those never
+#               configDir, mcpUrl, tabLabel, exhaustedPattern, errorPattern (fleetd #201 / #227 —
+#               compiled once into a startup pattern map the same way exhaustedPattern is). The
+#               launcher takes a copy of `profiles:` at startup and resolves every spawn out of
+#               that copy, so those never
 #               reach a launch until you restart. The reload logs them by name rather than
 #               pretending they applied.
 #   COLD      → cannot change at all: `bind:`, `herdrSocket:`, `broker:` and `auth:`. The socket is