Support branch_prefix in github-app.yml, mirroring the Project Settings override

## Summary

The per-project "Branch prefix override" setting (Project Settings → Branch prefix override, screenshot below) currently only lives in the app's local SQLite state (`projects.branch_prefix`) and must be set manually, per machine, through the UI. Please add a `branch_prefix` field to `.github/github-app.yml` so it can be version-controlled and shared automatically across a team, consistent with how `instructions`, `server_ready_pattern`, and `auto_open_in_browser` already work in that file.

## Current behavior

- Project Settings has a working "Branch prefix override" toggle + text field (supports `%username%`/similar placeholders, e.g. `%dat%-` → preview `%dat%-my-feature`).
- This setting is local-only: it lives in the per-user `~/.copilot/data.db` (`projects.branch_prefix` column) and has to be re-entered by every teammate, on every machine, for every clone of the project.
- `.github/github-app.yml` already supports several per-repo settings that mirror Project Settings fields 1:1 (`instructions`, `server_ready_pattern`, `auto_open_in_browser`, `automation.*`), but not `branch_prefix`.

## Proposed change

Add an optional `branch_prefix` field to the `github-app.yml` schema, e.g.:

```yaml
branch_prefix: "copilot-"
```

Behavior should match the existing UI field:
- Supports the same placeholder syntax (e.g. `%username%`).
- An explicit empty string (`branch_prefix: ""`) disables any prefix, matching the existing 3-state semantics already implemented for `projects.branch_prefix` (`NULL` = inherit global default, `""` = explicitly disabled, non-empty = literal override).
- Since this file already goes through a user trust/approval prompt before any of its settings are applied (per the existing `accept_repo_config`/`revoke_repo_config` flow), this fits naturally into the same trust model — no new security surface needed.

If it conflicts with the local per-project UI override, the more specific/most-recently-set value should probably win, or the UI field could simply be treated as read-only display of the effective value when set via config-as-code (whichever is simplest to reason about).

## Why this matters

Related open requests confirm real demand for consistent, shareable branch naming across a team:

- #363 — configurable prefix + context-derived branch slugs
- #1344 — branch renames getting "stuck" after the first rename
- #579 — custom worktree/branch naming at session creation

None of these solve the "make it consistent for my whole team without everyone manually configuring their own app" problem — which `github-app.yml` is exactly the right mechanism for, since it's already the config-as-code surface for other per-repo settings.

## Additional context

Filed after reverse-engineering the `github-app.yml` schema for #83 (doc gap) — happy to share findings on the current schema if useful for scoping this.

Bắt đầu với schema của `.github/github-app.yml` và cách xử lý hiện có cho `instructions`, `server_ready_pattern` và `auto_open_in_browser`. Theo dõi cách `accept_repo_config`/`revoke_repo_config` áp dụng các cài đặt đáng tin cậy và cách Project Settings đọc `projects.branch_prefix`. Công việc được xem là hoàn tất khi `branch_prefix` tùy chọn hỗ trợ các placeholder và giá trị rỗng tường minh mà không bỏ qua luồng tin cậy hiện có, đồng thời thứ tự ưu tiên giữa giá trị cục bộ và cấu hình được xác định và được kiểm thử.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.