CalendarDatePicker IsTodayHighlighted uses stale current date after app stays open across midnight

### Describe the bug

CalendarDatePicker / CalendarView appears to cache the "today" date when the control is first loaded. If a WinUI app remains open across midnight, the built-in today highlight still marks the previous date when the picker is opened later.

### Why is this important?

The today highlight looks authoritative in date-picking UI. If it marks yesterday or another stale date, users can believe the wrong date is "today" while editing dated records such as work logs, calendar entries, timesheets, or reports.

Apps can work around this only by disabling IsTodayHighlighted after detecting a stale CalendarView, but that removes a useful built-in cue instead of fixing it.

### Steps to reproduce the bug

1. Create a WinUI 3 app with a CalendarDatePicker or CalendarView and leave the control instance alive.
2. Open the app/control before midnight, then keep the app running across the local date change.
3. After midnight, open the CalendarDatePicker flyout or inspect the CalendarView.
4. Observe which date has the built-in "today" highlight.

### Actual behavior

The date that was current when the CalendarView was initialized remains highlighted as today.

### Expected behavior

The current local date should be highlighted as today when the CalendarView is shown or when visible day items are prepared.

### Screenshots

_No response_

### NuGet package version

Microsoft.WindowsAppSDK 2.2.0

### Windows version

Windows 11 (24H2): Build 26100

### Additional context

The likely issue is that CalendarView caches "today" in m_today and later compares day items against that cached value:

- CalendarView initializes m_today once in CreateCalendarAndMonthYearFormatter():
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/CalendarView_Partial.cpp#L988-L994

- CalendarViewGeneratorHost::PrepareItemContainer() compares each item against GetOwner()->GetToday():
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/CalendarViewGeneratorHost.cpp#L75-L93

- CalendarView::OnIsTodayHighlightedPropertyChanged() updates only the container matching cached m_today:
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/CalendarView_Partial.cpp#L1868-L1894

- CalendarDatePicker forwards the flyout Opened event:
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/calendardatepicker_partial.cpp#L165-L171

- CalendarDatePicker::UpdateCalendarVisibility() shows the flyout and calls SyncDate(), but does not appear to refresh CalendarView's cached today value:
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/calendardatepicker_partial.cpp#L371-L382

The generated CalendarDatePicker.g.cpp/.g.h files expose IsTodayHighlighted as a dependency property, but the stale value appears to come from CalendarView's cached m_today state rather than those generated accessors:
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/winrtgeneratedclasses/CalendarDatePicker.g.cpp#L178-L186
https://github.com/microsoft/microsoft-ui-xaml/blob/29d537445eaa34d47e66ab8859583ae953c62dd1/dxaml/xcp/dxaml/lib/winrtgeneratedclasses/CalendarDatePicker.g.h#L96-L97

Start with CalendarView_Partial.cpp, especially CreateCalendarAndMonthYearFormatter() and OnIsTodayHighlightedPropertyChanged(), then trace CalendarViewGeneratorHost::PrepareItemContainer() and CalendarDatePicker::UpdateCalendarVisibility(). Verify how m_today is initialized and used when the flyout opens after a local date change. Done means the current local date receives the IsTodayHighlighted treatment after the control remains open across midnight.

Written by the indexing model from the issue text.