Prompt Run Robustness Design

# Prompt Run Robustness, Concurrency, and Per-Row Failure Recovery

**Goal:** Make prompt runs robust to flaky LLM provider calls, durable across deploys, and capable of running in parallel without crowding each other or the host. Surface provider-side failures clearly so users can tell when an error is the provider's fault, not CompletionKit's.

This is the v2 follow-on to `2026-03-26-async-runs-design.md`, which explicitly deferred per-row retries and intra-run parallelism.

---

## Current Behavior

`Run#generate_responses!` and `Run#judge_responses!` each loop through their work synchronously inside a single ActiveJob (`GenerateJob`, `JudgeJob`). The queue adapter is `:async` in both `production.rb` and `development.rb`.

Failure modes today:

- A single `Faraday::Error` mid-loop flips the entire run to `failed`, throwing away every successful row that came before it. The user's only recourse is to click Generate again, re-spending every successful API call.
- `:async` jobs run in the web Puma's thread pool. A deploy or restart kills any in-flight run silently with no resumption.
- Solid Queue's schema is in `standalone/db/schema.rb` (migration `20260327200001_create_solid_queue_tables.rb`) but no code uses it.
- Concurrent runs share the in-process thread pool with no per-provider throttle, so two large simultaneous runs can trip provider rate limits.
- The `Run#status` enum (`pending → generating → judging → completed/failed`) treats generation and judging as strict sequential phases; judging cannot start until every row has finished generating, even though nothing forces this ordering.

---

## New Behavior

### Job topology

Each run fans out into row-level jobs that interleave generation and judging: