Feature: name each split pane in place, and rearrange it by dragging

[DevMando]

Summary

Split view gains a header on every pane naming the agent shown beneath it, and you rearrange the
layout by dragging rather than by picking agents from per-pane dropdowns. Dragging a tab onto a
pane places that agent there; dragging one pane's header onto another swaps them.

Why this matters

Split view could show two, three, or four agents at once, but nothing in a pane said which agent
it was. The names lived in a strip along the top, so identifying a pane meant matching position
against that strip — and with four panes of similar-looking conversations, that is genuinely hard.
Rearranging meant opening a dropdown per pane and choosing from a list, which is a lot of clicks
for something that is fundamentally spatial.

What is new

• Per-pane headers. Each pane names its own agent, so you read the name where the agent is.
• The tab strip becomes a list of what is not on screen. Agents already visible in a pane
  drop out of it, so the strip stops duplicating what you can already see.
• Drag a tab onto a pane to put that agent there, replacing whatever was in it.
• Drag one pane's header onto another to swap the two agents.
• Every drop target says what it will do before you release — replace, swap, or create.
• Dragging onto a single, unsplit chat starts a split, and the half you hover decides which
  side the dragged agent lands on. The agent you were already reading stays where it is.
• The per-pane dropdowns are gone. The tab menu still offers "Add to split view" for anyone who
  would rather not drag.
• The move cursor appears only over the agent's name, not over the badge or the ... button —
  those are things you click, and a move cursor there would promise a drag that cannot start.

Scope and risk

Medium. MainWindow.Split.cs is substantially reworked (+549/−), and split view is a feature
people arrange once and then rely on, so a regression here is annoying rather than subtle.

Things worth a reviewer's attention:

• Drag-and-drop in WinUI fails quietly when a target is not hit-testable. A Grid with a null
  Background previews a drop correctly but never fires it. That exact bug was hit and fixed here
  by giving the single-view target a scrim brush; all three drop targets were then audited for the
  same problem. It is the failure mode to re-check if any target is added later.
• ProtectedCursor applies to an element and its children, which is why the drag handle wraps
  only the label rather than the header row. Widening that wrapper would put the move cursor back
  over the ... button.
• Border is sealed, so the drag handle is DragHandleGrid : Grid. The cursor is set at
  Loaded rather than in the constructor — assigning it during construction fast-fails in WinUI.

Verification

• dotnet build src/MandoCode.Desktop — succeeded, 0 warnings, 0 errors.
• dotnet test src/MandoCode.Desktop.Tests — 489 passed, 0 failed.
• Drag, drop, swap, replace, and split-creation were exercised by hand in a running app, including
  the single-agent case where a drop starts the split.

Not covered, and worth being plain about: split view has no automated tests. Everything above
is either a build-level check or a manual pass. The drag-and-drop paths in particular are WinUI
input behaviour that the current test setup cannot reach, so the hit-testability bug described
above was found by clicking, not by a test, and a similar regression would be found the same way.

Rebase note

This branch predates the 0.15.0 changelog audit (#71) and the engine pin (#72). Rebasing it onto
main surfaced two stale edits it was carrying, both dropped rather than replayed:

• an older pin correction naming f4e0556, now superseded by d50bfb7 from Chore: pin the engine to the 0.15.0 release commit #72
• a duplicate of the snapshot/history/note deletion entry, which Docs: record the 0.15.0 work missing from the changelog #71 already added in better-sourced
  wording

The changelog diff here is therefore just the one new Added entry.