Expose `git.base_branch` in the dashboard Settings tab

[EnmaJim]

Problem statement

git.base_branch is the only setting that controls which branch Dotbot cuts task worktrees from and
squash-merges into. Verified end to end: setting it redirects merges away from the trunk, so it is the
one available answer for a team working on a long-lived branch instead of master.

// .bot/.control/settings.json
{ "git": { "base_branch": "feature/qa-work" } }

New-TaskWorktree      -> worktree-map base_branch = "feature/qa-work"
Complete-TaskWorktree -> "Squash-merged to feature/qa-work and cleaned up"
master unchanged; feature/qa-work advanced

But there is no way to set it other than hand-editing JSON:

• dotbot help lists no command for it; there is no dotbot config verb at all.
• src\ui\modules\SettingsAPI.psm1:447-477 already implements Get-GitConfig and Set-GitConfig, and
  exports both at :1355-1356 — but no HTTP route in server.ps1 calls them, and the Settings tab
  renders no control for them. A grep for settings/git across src\ui returns nothing.
• The file it lives in, .bot/.control/settings.json, is gitignored, so the value cannot be committed
  and shared. Every developer must recreate it on every machine, by hand, with no validation and no
  discoverable documentation.

The practical result is that a team hitting the wrong-merge-target behaviour (#679) has a working fix
available and no way to find it. Nothing in the failure message, the needs-input escalation, or
dotbot doctor mentions that this setting exists.

Proposed outcome

A Base branch field in the dashboard's Settings tab, under a Git section:

• Populated from Get-GitConfig; saved through Set-GitConfig (both already written).
• Validated against git branch --format='%(refname:short)' so a typo cannot be saved — currently an
  invalid value makes Resolve-DotbotBaseBranch:172 throw at run time
  (git.base_branch is set to 'x' but no such branch exists … refusing to fall back to main/master),
  which surfaces late and confusingly.
• Empty input stores null, preserving today's main → master probe. SettingsAPI.psm1:452-465
  already normalises empty string to null.
• Shown with the currently resolved value when unset (e.g. "unset — resolving to master"), so the
  operator can see what Dotbot will actually do.

A dotbot config get|set git.base_branch <branch> verb would cover the headless/CI case, but the UI
field alone would resolve the discoverability problem.

Worth pairing with the fix for #680: today the setting is honoured on the happy path but abandoned by
the three failure-path Assert-OnBaseBranch calls, so exposing it in the UI without that fix would
promise more consistency than it delivers.

Affected users / use case

Any team whose integration branch is not main or master — release branches, develop, or a long-lived feature branch shared by several people. This is the reported configuration of at least one team hitting #679, and it is the only supported way to stop Dotbot writing to the trunk.

Rough size

S

Additional context, links, mockups

The API layer is already done; this is one HTTP route plus one input control. For reference, the value
resolves correctly only when a BotRoot is supplied:

Resolve-DotbotBaseBranch -ProjectRoot <r> -BotRoot <r>\.bot   ->  feature/qa-work
Resolve-DotbotBaseBranch -ProjectRoot <r>                     ->  master

Settings layers, low → high (Dotbot.Settings.psm1:130-135), so .bot/.control/settings.json wins:

<DOTBOT_HOME>\content\settings\settings.default.json
<BotRoot>\content\settings\settings.default.json
%APPDATA%\dotbot\user-settings.json
<BotRoot>\.control\settings.json        <- highest, gitignored

A tracked alternative already exists — <BotRoot>\content\settings\settings.default.json is committed —
so documenting that path as the place to set a shared base branch would help teams immediately, even
before any UI work.