TimePicker and DatePicker should honor explicit Width and Height on their visible selector controls

### Problem

`TimePicker`, `DatePicker`, and `CalendarDatePicker` do not fully honor explicit `Width` and `Height` values on their visible, closed selector control.

The outer `FrameworkElement` accepts the requested dimensions, but the default templates keep sizing the inner selector button from fixed theme resources and intrinsic content. This makes the controls difficult to place side by side and can cause clipping or overflow when a compact size is requested.

### Minimal repro

```xml

```

The same behavior is relevant to `CalendarDatePicker` when it is constrained to a compact explicit size.

### Current template details

The current WinUI templates define fixed selector sizing resources and apply them to the inner `FlyoutButton`:

- [`TimePicker_themeresources.xaml`](https://github.com/microsoft/microsoft-ui-xaml/blob/winui3/main/controls/dev/CommonStyles/TimePicker_themeresources.xaml) defines `TimePickerThemeMinWidth` as `242` and `TimePickerThemeMaxWidth` as `456`.
- [`DatePicker_themeresources.xaml`](https://github.com/microsoft/microsoft-ui-xaml/blob/winui3/main/controls/dev/CommonStyles/DatePicker_themeresources.xaml) defines `DatePickerThemeMinWidth` as `296` and `DatePickerThemeMaxWidth` as `456`.
- Both templates apply the fixed minimum/maximum to the internal selector button instead of deriving the closed selector dimensions from the parent control's explicit layout constraints.

### Expected behavior

When the caller explicitly sets `Width` and/or `Height`:

1. The closed selector control should render at the requested size, subject to normal content/layout constraints.
2. The internal hour/minute/period or day/month/year columns should resize with the selector instead of retaining a larger fixed minimum.
3. The requested height should size the closed selector button predictably, including correct handling of `Header`.
4. When `Width` and `Height` are not explicitly set, the existing comfortable default dimensions should remain unchanged.
5. The flyout/presenter may retain an independent minimum width if needed for usable picker columns; the closed control and flyout should not be forced to share the same minimum.

### Related issues

- #8950 — Inconsistent control height and spacing between the control and its `Header` for `TimePicker` and `CalendarDatePicker`
- #6709 — DatePicker MaxWidth

### Environment

Observed with WinUI 3 / `Microsoft.ui.xaml.dll` 3.2.1 on Windows 11. The issue also appears directly attributable to the current WinUI control templates and should be reproducible in a minimal WinUI 3 XAML app.

Start with TimePicker_themeresources.xaml and DatePicker_themeresources.xaml, then reproduce the minimal WinUI 3 XAML example with explicit Width, Height, and Header values. Check the closed selector sizing for TimePicker, DatePicker, and CalendarDatePicker while preserving comfortable defaults and allowing the flyout to keep an independent minimum width. Done means explicit dimensions are honored without clipping or overflow.

Written by the indexing model from the issue text.