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.

Beginne mit dem Schema von `.github/github-app.yml` und der bestehenden Verarbeitung für `instructions`, `server_ready_pattern` und `auto_open_in_browser`. Verfolge, wie `accept_repo_config`/`revoke_repo_config` vertrauenswürdige Einstellungen anwendet und wie `projects.branch_prefix` von Project Settings gelesen wird. Die Arbeit ist abgeschlossen, wenn ein optionales `branch_prefix` Platzhalter und explizite leere Werte unterstützt, ohne den bestehenden Vertrauensfluss zu umgehen, wobei der Vorrang von lokal gegenüber der Konfiguration definiert und durch Tests abgedeckt ist.

Vom Indexierungsmodell aus dem Issue-Text verfasst.