fix(bud-closure): prevent running code synthesis on BUD close

[mickyarun]

Summary

• Remove the _trigger_impacted_repo_scan side effect from services/bud_closure.on_bud_closed. Repo scans now live exclusively in the PR-merge GitHub webhook (api/v1/github_webhook.py → services/scan/pr_merge_update.py), which already gates on the repo's main_branch.
• Keep every other BUD-close side effect: contributor XP, BUD-shipped SP, BUD learning metrics (CLOSED only), post-close Learning Agent. The linked-features in_progress → done transition continues to run upstream in bud.py via feature_lifecycle.transition_feature_for_bud, unchanged.
• Update CLAUDE.md and CHANGELOG.md so future readers find the scan trigger in the right place; tighten the stale comment in api/v1/bud.py:986.

Why

Forensic investigation of prod on 2026-06-02 showed that closing BUD #8 fired an incremental repo scan against the impacted repo at whatever HEAD that repo happened to be on. The scan had no main-branch / merge / deployment / HEAD-advance check. Because the full-scan reconciler in services/scan/stages/synthesize.py:362 does not pass deactivate_filter, every active feature the narrow BUD-impact synthesis didn't re-confirm got sweep-deactivated.

Concretely: BUD #8 ("Fail-loud on Rapyd webhook ↔ API status divergence so retry cron picks it up") was a narrow fix in one impacted repo. Closing it triggered scans row baa9b580-1d4d-45d0-b6ab-71a63bd0938b, which then flipped 10 cross-cutting features (Permissions & Roles, Auth Context, Sandbox Refunds, Application Configuration, Build/Test/Process Tooling, Pagination, Payment Link Detail Models, Role-based Access Control Middleware, Service URL Manager, Platform Reference Enums) to is_active=false at SHA 96cd92d… — a SHA the BUD never shipped to main and that no merge-to-main event ever produced. The user invariant is "scans only run when a merge with main happens"; this restores that invariant for the BUD-closure path.

The full-fallback reconciler sweep is a separate defect (Stage 2, follow-up PR) that also affects PR-merge above the narrow-cap. This PR addresses the trigger gap only.

Test plan

• ruff check backend/ — zero issues.
• ruff format --check backend/app/services/bud_closure.py backend/app/services/bud_metrics.py — already formatted.
• mypy backend/app/ — 492 source files, no issues.
• pytest backend/tests/ — 1814 passed, 0 failed.
• pr-review-toolkit:code-reviewer subagent review — addressed both findings (stale CHANGELOG.md:28 claim and stale bud.py:986 inline comment).
• Local end-to-end repro. Reverted local BUD 246 (Notification bell icon redesign, impacted repo taskflow-web) from closed to prod. With the patch loaded (uvicorn --reload auto-restart confirmed via PID start time), PATCH /api/v1/buds/eb3a389c-… {status: "closed"} returned 200 and:
  • scans count: 3 before, 3 after — no scan triggered ✅
  • features for the impacted repo: 5 active / 0 inactive before and after — no sweep ✅
  • BUD 246 status: closed (transition succeeded) ✅
• Post-merge prod observability: confirm via prod DB that no scans row appears in response to BUD close events going forward; PR-merge webhooks continue to create scans rows as before.

Follow-up

Stage 2 (separate PR) will fix the reconciler matching defect that causes the full-scan path to mass-deactivate features whose new synthesis has a different cluster_signature despite cosine similarity ≥ 0.85 (e.g. "Cache Service" ↔ "Cache Service", "Vendor Rollout Flags" ↔ "Vendor Rollout Flags") — see the plan file for the design.