Phase A landed the schema; this lights it up. Claims can now be
created via API, expire on schedule, and be fulfilled by an
incoming submission.

  * POST /api/v1/claims — new endpoint at the start of a v1 API
    namespace (existing flat routes stay where they are). Auth
    mirrors SubmissionsController exactly: `submitter` block with
    email/password/computer, password verified by bcrypt against
    the User, computer scoped to the authenticated user's
    computers. Build-scope claims set expires_at 15 min out; test-
    scope claims look up the matching TCC by (module, name) on the
    claimed commit and get 12 h. Distinct error paths for unknown
    SHA (404), missing test case on the commit (404), unknown
    scope (422), and missing test-case identifier on test scope
    (422), so a misbehaving client gets a precise signal rather
    than a generic validation dump.
  * Claim.default_expires_at + TTL_FOR_SCOPE constants — TTL
    values own the model side, controller stays at the HTTP
    boundary. 15 min / 12 h matches the V1 design in
    docs/dispatcher-and-claims.md.
  * Claim#fulfill! — flips a claim to `fulfilled` and stamps
    fulfilled_at. Idempotent across both legal starting states
    (pending OR expired) — a late submission that arrives after
    the sweeper has expired its claim still legitimately credits
    it. Uses update_columns so a stale `updated_at` race against
    the sweeper can't reject the write.
  * Claim.sweep_expired! + `rake claims:sweep` — bulk UPDATE
    backed by the partial index `index_claims_on_expires_at_pending`
    on (expires_at) scoped to pending rows. Cheap; Railway cron
    fires it every ~5 min. Logic lives on the model so it's
    unit-testable without rake plumbing.
  * Submission `after_create_commit :fulfill_claim` — when a
    submission POST carries a `claim:` block in the payload
    (claim_id + started_at + use_* flags), the matching claim is
    fulfilled as the create commit settles. Backwards-compatible:
    legacy mesa_test versions that don't send the block continue
    to work unchanged; the resulting submission has claim_id NULL
    and the callback short-circuits via its `if: claim_id.present?`
    guard.
  * 23 new specs covering: claim endpoint happy + sad paths (build
    + test, unauthenticated, wrong password, foreign computer,
    unknown commit, bad scope, missing TCC, dispatched_at echo);
    TTL helper output; fulfill! across pending + expired starting
    states + the stale-row race; sweep_expired! transitions +
    idempotency + leaves-fulfilled-alone + updated_at refresh;
    submissions integration (claim_id fulfills pending claim,
    claim_id fulfills expired claim for late-submission case, no
    claim block is a no-op).

403 specs total, all green.

Pre-claims, the only signal we had for "work is in flight on this
commit" was "the TCC has no submissions yet" — which fires the
instant a commit is ingested, well before any human has touched
the SHA. That made every freshly-ingested commit look like
something was actively running on it, and made the all-builds-
failed case lump unretried tests into pending. Both were wrong;
nobody was working on those commits.

Now that claims exist, this turns out to be a one-line gate at
each aggregation site:

  * `Commit#has_pending_claims?` and the matching pre-filtered
    `has_many :pending_claims` association — cheap presence check
    that plays nicely with `.includes(:pending_claims)` on the
    commits-index render path (no N+1 across 25 rows). Same shape
    on TestCaseCommit, plus `TCC#pending?` for the
    "untested-but-claimed" view-level question.
  * `CommitState#tests_status` — the `:pending` / `:not_run`
    branch now keys on `has_pending_claims?`, not on
    "`counts[:untested] > 0`." A commit with TCCs sitting at
    status=-1 and no live claim reads as `:not_run` (truly
    untouched). The instant a build or test claim lands, it
    flips to `:pending` (or `:pending_partial` if some tests
    already passed).
  * `CommitState#commit_state` row-classification loop — the
    `no_data ⇒ pending_tests += 1` fallback now requires the
    TCC to actually have a pending test-scope claim. Cell-level
    pending (computer built but no test result yet) still counts
    regardless of claims; that's a different signal.
  * `CommitState#_tccs_for_matrix` now eager-loads
    `pending_claims` so per-TCC `has_pending_claims?` reads from
    the loaded association.
  * `commits#index` extends the include set to cover both
    `commit.pending_claims` and `tcc.pending_claims` so a single
    page render stays at the same query count it had before.

19 new specs cover: tests_status :pending vs :not_run across
claim states; the `pending_tests` hero count over the same
states; Commit and TCC `has_pending_claims?` and `pending?`
predicates including the load-vs-query-shape check that protects
the index from N+1; revert-on-fulfill / revert-on-expire
transitions. One pre-existing spec that asserted the leaky
behavior ("counts tests with no built-computer results as
pending") was updated in place to test the new semantics —
`pending_tests = 0` without claims, `= 2` with two test-scope
claims out.

421 specs total, all green.