Benchmark SplitContainer repaint performance and resource stability

## Objective

Create a reproducible benchmark and stress harness that quantifies splitter-movement cost and detects memory or resource leaks during heavy resize/redraw activity.

## Measurements

Capture before/after numbers for:

- Interaction or iteration throughput.
- Elapsed time and CPU usage.
- Managed allocations and retained managed memory after forced collection and stabilization.
- Process working set and private bytes.
- GDI and USER object counts.
- Window/control handle counts where available.
- Layout, invalidation, and paint frequency when measurable without distorting results.
- Responsiveness under light, medium, and deeply nested heavy panel payloads.

## Method

- Automate repeated splitter movement across a fixed range in both orientations.
- Include warm-up, measurement, and post-run stabilization phases.
- Use enough iterations and duration to reveal monotonic growth.
- Separate one-time caches from sustained leaks.
- Compare the baseline and proposed implementation on the same machine and configuration.
- Record runtime, architecture, visual mode, theme, payload, build configuration, iteration count, and machine details.
- Prefer existing repository benchmark/test infrastructure. If a formal microbenchmark would misrepresent UI behavior, use a deterministic stress harness and document why.

## Completion criteria

- [ ] The methodology is reproducible and checked into an appropriate test or benchmark location.
- [ ] Baseline and fixed-build numbers are recorded.
- [ ] Light, medium, and heavy payloads are measured.
- [ ] No sustained managed/native memory, GDI/User object, or handle growth is observed.
- [ ] CPU and responsiveness costs are quantified and judged acceptable.
- [ ] Any measurement limitations or expected one-time caching effects are documented.

Start by locating the existing repository benchmark or test infrastructure and the SplitContainer implementation, then determine where a reproducible UI stress harness belongs. Run the baseline and proposed builds with light, medium, and heavy nested panel payloads, recording the specified performance, memory, object, handle, and responsiveness measurements. Done means the methodology and results are checked in, limitations are documented, and no sustained resource growth is observed.

Written by the indexing model from the issue text.