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.

Commencez par le schéma de `.github/github-app.yml` et la gestion existante de `instructions`, `server_ready_pattern` et `auto_open_in_browser`. Suivez comment `accept_repo_config`/`revoke_repo_config` applique les paramètres de confiance et comment Project Settings lit `projects.branch_prefix`. Le travail est terminé lorsqu’un `branch_prefix` facultatif prend en charge les espaces réservés et les valeurs vides explicites sans contourner le flux de confiance existant, avec la priorité entre le local et la configuration définie et couverte par des tests.

Rédigé par le modèle d'indexation à partir du texte de l'issue.