feat(control-plane): resolve review preset from repo config per entry point (ADR-0103)

[stephane-segning]

1. Summary

This PR changes:

• Every task-creation entry point (webhook auto-PR-open, @mention, A2A review skill) now resolves
  its review preset from repo config (.lightbridge-code-review.jsonc, ADR-0030) instead of a
  hardcoded "fast"/"deep" literal.
• New CodePlatform::get_repo_file trait method — a single small file fetch, never a clone —
  implemented across GitHub (Contents API), GitLab (Repository Files API), and Bitbucket (Source
  API).
• New services/control-plane/src/preset.rs: EntryPoint (pr_open/mention/a2a) +
  resolve_preset, reading the repo config's preset/entry_points fields at the PR's base ref
  (fork-safe by construction — a fork PR can't rewrite its own preset by editing the file on its own
  branch). Every failure mode (fetch error, absent file, oversized, malformed JSONC) degrades to the
  platform-default entry-point mapping, reproducing today's ADR-0062 fast/deep split exactly for a
  repo that configures nothing.
• Migration 0033_task_preset.sql: tasks.tier renamed to tasks.preset (hard cutover, no compat
  column) plus a new tasks.entry_point column.
• Every hardcoded tier: "fast"/"deep" call site swept: webhook.rs (6 sites across GitHub/GitLab/
  Bitbucket), a2a/handler/lifecycle.rs, db/tasks.rs, agent-clients' TaskContext,
  agent-runner's run.rs.

It solves:

• Story [Story]: Entry points resolve review preset from repo config #495 (entry points resolve preset from repo config), part of epic [Epic]: Repo-configurable OpenCode review presets (retire fast/deep tiers) #491. Builds on refactor(review): generalize ReviewConfigs to named presets, remove fast:bool (ADR-0103) #527/feat(review): implement the .lightbridge-code-review.jsonc repo config reader (ADR-0030) #528
  (ReviewConfigs generalization + the .lightbridge-code-review.jsonc reader) — this PR is what
  makes preset selection actually reach production traffic.

---

2. Intent

The preset config schema (story #494) is useless until every task-creation call site reads it
instead of hardcoding "fast"/"deep". This PR closes that gap: the control plane fetches the
repo's config at webhook time (a single cheap file read via the platform's API — control-plane never
clones repos, that's the agent-runner Job's job after the task already exists), resolves a preset
per entry point, and persists both the resolved preset and which entry point created the task —
because a preset name is now operator-defined and can no longer double as an intent signal for
presentation decisions like "was this the automatic on-open pass" (the old context.tier == "fast"
banner check, now context.entry_point == "pr_open").

---

3. Scope

In Scope

• CodePlatform::get_repo_file + 3 platform implementations.
• preset::resolve_preset/resolve_preset_or_default + EntryPoint.
• DB migration + full call-site sweep (webhook.rs, a2a lifecycle, db/tasks.rs, agent-clients,
  agent-runner).
• The internal.rs banner-vs-full-body fix (keyed off entry_point, not preset name).
• Two new wiremock-backed end-to-end integration tests (custom preset resolved; no-config fallback)
  plus unit tests for the resolver's pure logic.

Out of Scope

• A2A entry point does not resolve preset from repo config — it uses the platform default
  (deep) directly. The A2A role holds no forge credentials by design (its own module doc: "this role
  NEVER launches a Job or touches a forge... holds no forge credentials") — giving it a CodePlatform
  client to fetch config would hand it the ability to call every other platform method too (post
  reviews, mint tokens), which is exactly the trust boundary that doc comment exists to prevent. This
  is a deliberate, documented scope boundary, not an oversight.
• The ultra preset's own model/budget definition (story [Story]: ultra preset with frontier-model config #496).

---

4. Verification

I verified this change by:

• Running automated tests (against a real Postgres, not just compiled)
• Checking logs (test output below)

Commands run:

cargo build --workspace --all-targets
export DATABASE_URL="postgres://<local test postgres>"
cargo test -p control-plane --bin control-plane
cargo test -p lci-agent-clients -p agent-runner

Results:

$ cargo build --workspace --all-targets
Finished `dev` profile [unoptimized + debuginfo] target(s) — 0 errors

$ cargo test -p control-plane --bin control-plane
test result: ok. 341 passed; 0 failed; 2 ignored (Neo4j-dependent, unrelated)

  Notably, among the 341:
  - preset::tests::* (6) — resolve_from_config pure-logic coverage (flat preset, per-entry-point
    override precedence, no-config fallback, unrelated-field tolerance)
  - http::webhook::tests::mr_open_resolves_a_custom_preset_from_repo_config — wiremock-backed,
    end-to-end: MR-open webhook → GitLab Repository Files API → JSONC parse → task row's `preset`
    column
  - http::webhook::tests::mr_open_falls_back_to_the_platform_default_preset_when_no_repo_config_exists
    — same path, 404 from the mocked API → falls back to `fast`
  - db::tests::get_task_context_joins_repo_identity — preset/entry_point round-trip through the new
    migration's columns

$ cargo test -p lci-agent-clients -p agent-runner
test result: ok. 69 passed; 0 failed  (agent-runner)
test result: ok. (agent-clients — all green)

---

5. Screenshots / Evidence

Not applicable — backend config/behavior addition, no UI surface.

---

6. Risk Assessment

Risk level:

• Low
• Medium
• High

Potential risks:

• Breaking DB migration: tasks.tier → tasks.preset is a rename (no compat column, per this
  repo's hard-cutover convention) — every read/write call site had to be updated in the same change,
  which is exactly the kind of sweep a missed site fails silently on. Mitigated by: the full existing
  control-plane test suite (341 tests, unchanged assertions except field renames) staying green against
  a real database, which would have caught a missed/mismatched column reference.
• New platform API surface: get_repo_file is new, untested-in-production code on the webhook hot
  path for every PR-open/@mention event. A slow or failing GitHub/GitLab/Bitbucket API call adds
  latency to task creation. Mitigated by: every error path (fetch failure, timeout, 404, oversized,
  malformed) degrades to the platform-default preset rather than blocking or failing task creation —
  proven by the mr_open_falls_back_to_the_platform_default_preset_when_no_repo_config_exists test.
• A2A scope boundary: documented above (Scope) — flagging again here since it's a real, deliberate
  limitation a reviewer should confirm they agree with, not something to silently accept.

Mitigation:

• Full workspace build + full control-plane suite (341 tests) verified against a real Postgres
  instance, not just cargo check.
• Every degrade-to-default path in preset.rs logs a tracing::warn! naming the reason, so a
  misbehaving platform API call is diagnosable from run logs.

---

7. AI Usage Declaration

AI was used for:

• Understanding existing code
• Generating code
• Refactoring
• Generating tests
• Drafting documentation
• Reviewing the diff
• Not used

Human verification:

• I understand every meaningful change in this PR
• I checked generated code manually
• I checked generated tests manually
• I removed unsupported AI assumptions
• I accept responsibility for this PR

AI-drafted (Claude) for @stephane-segning's review — human-verification checkboxes intentionally
left unticked; only the accountable owner can truthfully check them.

---

8. Reviewer Focus

Please focus your review on:

• Correctness
• Architecture
• Security
• Performance
• Tests
• Maintainability
• Product intent
• Edge cases

Source of truth: #495
(epic #491),
ADR-0103.

This PR is stacked on #528 (story
#494's repo-config reader, not yet merged) — its base branch is claude/stories-494-495-496-b0cd38,
so this diff will shrink to just story #495's changes once #528 merges and this PR's base auto-updates
to main. The ultra preset (story #496) is a separate follow-on PR against the same epic.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 97213d1

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[github-actions]

✅ AI Governance check passed

This PR declares AI usage, references a source of truth, and provides verification evidence. Thank you.