feat(buds): per-BUD branch override for UAT / PROD tabs

[mickyarun]

Summary

Lets a BUD opt out of the repo-wide tracking branch and watch its own pattern instead. Useful for release-train BUDs whose PRs target release/* and one-off ad-hoc release branches that don't belong in the global repo setting.

Builds on top of #193 (PR 1). Without #193's broadened resolver + three-way query predicate the over-matching bug returns the moment you set any override — both PRs are needed for the full fix.

What changed

Backend

• New branch_overrides JSONB column on bud_documents keyed by stage (uat / prod) with fnmatch-style values. Migration is autogenerated, nullable, no backfill needed.
• BUDUpdate accepts branch_overrides and impacted_repos on PATCH. The validator rejects unknown stage keys (UAT, production, code_review), empty / whitespace patterns, and non-string values — typos surface as 422 at the API edge instead of fnmatching nothing.
• PATCH handler merges branch_overrides per-key so saving a UAT override doesn't clobber an existing prod override. {stage: null} drops just that key; branch_overrides: null wipes both.
• bud_prs.py::release_stage honors bud.branch_overrides[stage] before falling back to repo.uat_branch / repo.main_branch. Reuses the existing branch_matches() fnmatch utility — wildcard semantics stay consistent with release detection.
• Editing impacted_repos after the planning phase logs bud_impacted_repos_edited_post_planning so post-deploy auditing of scope changes is possible.

Frontend

• New BUDStageBranchOverride.vue widget rendered inside the shared BUDReleaseStagePanel.vue. Shows the currently-effective pattern (override or repo default), an Edit affordance opening an inline dialog, and — for multi-repo BUDs — a one-line applies to N repos disclosure so the per-stage scope is explicit before saving.
• Save → PATCH /v1/buds/{id} with branch_overrides; the panel re-fetches its stage data on success and emits refresh-bud so BUDDetail pulls the new override into the prop feed.
• Empty input on Save and the dedicated Clear override button both send {[stage]: null} — the merge-aware handler drops just that key, leaving the sibling stage untouched.

Test plan

• cd backend && pytest tests/schemas/test_bud_branch_overrides.py -q — 16 cases pass (accept valid stage keys + clear signal; reject unknown keys, wrong case, empty / whitespace, non-string).
• Full backend suite green: 1836 passed, 0 failed.
• vue-tsc --noEmit clean.
• In the UI: open a BUD's UAT tab → Edit tracking branch → set release/* → save. Confirm the PRs targeting release/2026-08-01 start appearing.
• Set a UAT override, then set a Prod override — confirm the UAT one is still in place (merge, not replace).
• Clear the Prod override via the Clear override button — confirm UAT is still in place and Prod falls back to the repo-wide main_branch.
• Try to save " " — confirm the 422 must be a non-empty pattern or null surfaces inline.

Notes

• Per-stage scope (not per-repo-per-stage) is a deliberate choice. Multi-repo BUDs whose repos disagree on the stage branch shape are expected to use a wildcard pattern (release/*) that matches all of them; the dialog explicitly tells the user this on multi-repo BUDs.
• Migration is safe to deploy ahead of the new code: column is nullable and existing reads ignore it; new reads use (bud.branch_overrides or {}).get(stage) so the absence is the silent fallback path.