feat(sessions): watch CI on published merge requests and bound the fix attempts

[srtab]

After DAIV publishes a merge request, it now watches that MR's CI and spends a bounded number of agent runs trying to make it green, then hands back to a human with a diagnosis.

Implements docs/superpowers/specs/2026-08-25-pipeline-watch-design.md.

How it works

• Arm — the post-run block of run_job_task points a watch at the MR the run just published (state lives on Session: watch_state, watch_attempts, watch_pipeline_id, watch_armed_at) and enqueues an immediate evaluation, because the push already happened during publish so the CI event can arrive before the watch exists.
• React — new CI webhooks on both platforms (GitLab pipeline_events, GitHub workflow_run) enqueue evaluate_pipeline_watch_task on the interactive queue.
• Judge — a pure function classifies a finished pipeline GREEN / ACTIONABLE / UNCLEAR. Deliberately conservative: only an unambiguous failed is actionable; blocked/manual/skipped/canceled and zero-job pipelines are UNCLEAR, which stops the watch with an explanatory MR note and spends no attempts. The zero-job case is real — a private cross-project include resolves as the pushing identity, and an ephemeral per-project bot can't read it.
• Fix — an actionable failure dispatches an agent run on the MR's own thread and branch, with a small prompt naming the failed jobs and pipeline URL (no embedded logs; the agent has trace tools). At the cap the watch goes exhausted, comments on the MR, and notifies once.
• Reconcile — a cron sweep every 10 minutes catches missed events and stuck states; a watch idle past 6h goes unclear.

Loop safety

The feature spends real money per attempt, so the bound is the design's centre of gravity. watch_attempts is incremented at dispatch behind a primary-key compare-and-swap (so a losing racer cannot dispatch), never reset when a fix run re-arms, and the cap is read per dispatch from repo config clamped by site settings. watch_pipeline_id dedupes repeat events on both the webhook and poll paths, and a fix run that produces no diff ends the watch immediately — no diff means no push, so no pipeline and no event would ever arrive.

Configuration

pipeline_watch_enabled (default true) and pipeline_watch_max_attempts (default 3, min 1), site-wide under Configuration → Pipeline Watch, overridable per repository in .daiv.yml:

pipeline_watch:
  enabled: true
  max_attempts: 3

A repository can tighten or disable; the operator holds the master switch (both are clamped at every consumption site).

Rollout — required, and it differs per platform

• GitLab: python manage.py setup_webhooks --update. setup_webhooks skips hooks that already exist without --update, so without this the feature is inert on every already-onboarded repository.
• GitHub: subscribe the GitHub App to Workflow run. The management command returns early on GitHub, so it is not the GitHub path.

Both checklists in docs/getting-started/platform-setup.md are updated.

Notes for review

• accept_callback on both new callbacks deliberately does not reject events attributed to DAIV, unlike every other callback here. On repos using project-scoped ephemeral push tokens the publisher pushes with [skip ci] and heals CI as the service account, so the pipeline most worth watching is attributed to DAIV itself. test_a_pipeline_daiv_triggered_is_still_accepted guards this; loop protection comes from the attempt counter, never from identity.
• Job.status's Literal gained preparing, waiting_for_resource, canceling and waiting_for_callback — this is the first code to populate Job from the GitLab jobs API, so the narrower vocabulary became reachable.
• The GitHub Actions API doesn't expose per-job required-ness, so that client treats every job as required: a continue-on-error failure counts as real. Conservative direction — can cost a wasted attempt, never misses a failure.
• Three migrations: core/0016, sessions/0007, notifications/0008. sessions/0007 rebuilds both check constraints keyed on SessionOrigin.values (session_origin_valid and run_trigger_type_valid).

Known gaps, deliberately not in this PR

• The watch arms only in run_job_task, so it covers API/MCP/UI jobs, scheduled runs and chat — but not issue-webhook or MR-comment-webhook publishes, which drive their managers directly. The spec chose this arm site deliberately, but its Scope section's caveat about issue-originated MRs implies broader reach. Widening it is new design work.
• A dead fix run currently ages out silently at 6h rather than being re-judged: the reconciler's un-stick sweep doesn't clear watch_pipeline_id, so the next poll dedupes and returns. One-line fix, follow-up.
• The enqueue in _adispatch_fix_run is unguarded, unlike asubmit_batch_runs; a broker failure spends the attempt and leaves an unreaped READY Run row.
• The site master switch doesn't drain already-armed watches — webhooks stop at once, but the poll path can still spend the remaining cap per armed MR until the 6h expiry.

Verification

• make test — 4699 passed, 90.22% coverage
• ruff check + format --check clean; mkdocs build --strict clean
• make lint-typing — 463 diagnostics, all pre-existing Django field-descriptor false positives, no new error class
• All three migrations apply cleanly to a fresh database